Docker: le lecteur n'a pas été partagé

Lorsque j'ai "ancré" une application MVC ASP.NET Core 3.1 , j'ai obtenu le résultat suivant:

docker run -dt -v "C:\Users\admin\vsdbg\vs2017u5:/remote_debugger:rw" -v "D:\xxx\yyy\Spikes\DockerizedWebApp1\DockerizedWebApp1:/app" -v "D:\xxx\yyy\Spikes\DockerizedWebApp1:/src/" -v "C:\Users\admin\.nuget\packages\:/root/.nuget/fallbackpackages2" -v "C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -e "ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS=true" -e "ASPNETCORE_ENVIRONMENT=Development" -e "NUGET_PACKAGES=/root/.nuget/fallbackpackages2" -e "NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages;/root/.nuget/fallbackpackages2" -P --name DockerizedWebApp1 --entrypoint tail dockerizedwebapp1:dev -f /dev/null
docker: Error response from daemon: status code not OK but 500: {"Message":"Unhandled exception: Drive has not been shared"}.
See 'docker run --help'.
C:\Users\admin\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.10.6\build\Container.targets(198,5): error CTC1015: Docker command failed with exit code 125.
C:\Users\admin\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.10.6\build\Container.targets(198,5): error CTC1015: docker: Error response from daemon: status code not OK but 500: {"Message":"Unhandled exception: Drive has not been shared"}.
C:\Users\admin\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.10.6\build\Container.targets(198,5): error CTC1015: See 'docker run --help'.
C:\Users\admin\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.10.6\build\Container.targets(198,5): error CTC1015: If the error persists, try restarting Docker Desktop.

Inutile de dire que « docker run --help » n'a pas aidé du tout (liens / ancres manquants dans les documents Docker, etc.).

Quelques informations supplémentaires:

L'application est ce que les échafaudages VS2019 sans aucune modification .
L'image Docker est Linux ( que je ne peux pas dire ).
La version Docker est 19.03.5, build 633a0ea

Étant donné que je ne connais pas Linux, cette erreur se révèle être pour moi un "stop-show". Peut-être que Linux n'est pas chargé de monter un lecteur? Mais lequel? Le message ne le dit pas ...

Peut-être que Windows doit partager un lecteur ou mapper un dossier sur un lecteur qui doit être partagé? Le message ne le dit pas non plus ...

Voici une capture d'écran du tableau de bord Docker:

Et voici le Dockerfile:

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src 
COPY ["DockerizedWebApp1/DockerizedWebApp1.csproj", "DockerizedWebApp1/"]
RUN dotnet restore "DockerizedWebApp1/DockerizedWebApp1.csproj"
COPY . .
WORKDIR "/src/DockerizedWebApp1"
RUN dotnet build "DockerizedWebApp1.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "DockerizedWebApp1.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DockerizedWebApp1.dl"]

Toute aide serait très appréciée. Merci d'avance!

docker asp.net-core Alexander Christov
la source

Réponses:

La commande docker run inclut les volumes du lecteur C, par exemple -v "C:\Users\admin\vsdbg\vs2017u5:/remote_debugger:rw". Pour que cela fonctionne, vous devez inclure le lecteur C dans vos lecteurs partagés (cochez la case sous paramètres -> ressources -> partage de fichiers). Vous pouvez également déplacer les fichiers à partager sur le lecteur D qui est déjà partagé sur la machine virtuelle intégrée, bien que ce ne soit probablement pas une option dans ce cas. Pour savoir quels lecteurs partager, vérifiez les lecteurs utilisés dans les montages de volume dans la commande run.

Dans les versions précédentes de docker pour Windows, cela réussissait en silence et montait un dossier vide dans le conteneur. L'erreur indiquant aux utilisateurs de vérifier d'abord les lecteurs partagés est donc une belle amélioration.

BMitch
la source

C: est mon lecteur de démarrage et le système d'exploitation y est installé. Pensez-vous vraiment que c'est une bonne pratique de partager une information aussi sensible?

Alexander Christov

@AlexanderChristov, le lecteur est partagé avec la machine virtuelle intégrée, ce qui vous permet de monter des répertoires à partir de celui-ci dans le conteneur. Vous ne pouvez pas dire que vous ne voulez pas partager le lecteur tout en souhaitant également exécuter des commandes qui nécessitent un accès aux répertoires sur ce lecteur. Ce n'est pas un problème de docker, c'est un problème avec la commande que vous demandez à docker d'exécuter.

BMitch

toujours "Voir 'docker run --help'." est tout à fait inutile. En fait, il est quelque peu nocif car conduit à une pure perte de temps, ce qui, comme vous pouvez le voir, a conduit à poser la question. de toute façon, merci.

Alexander Christov

@AlexanderChristov est un message générique pour toute commande qui échoue, vous permettant de savoir quel texte d'aide de sous-commande peut être pertinent. Je ne sais pas comment régler cela pour couvrir toutes les conditions d'erreur possibles. Le 500: {"Message":"Unhandled exception: Drive has not been shared"}message qui a déclenché l'erreur est la partie utile.

BMitch

Voir ceci pour savoir où / quand ils génèrent cette --helpinvite: github.com/moby/moby/blob/…

BMitch

Rendre le lecteur C: disponible pour les conteneurs Docker à partir du tableau de bord Docker a résolu le problème , regardez à nouveau l'image où elle n'a pas été vérifiée.

Cependant, quelques commentaires doivent être partagés à mon humble avis.

Le message d'erreur n'était pas clair sur le lecteur à partager (Linux prend en charge plusieurs lecteurs , je suppose)
Si sans rendre le lecteur C: disponible (ou le lecteur de démarrage, celui où réside le système d'exploitation) Docker ne serait pas fonctionnel , pourquoi après son installation, il n'a pas vérifié le lecteur lui-même? Ce n'est qu'un clic ( !! ) dans le Docker Dashboard, donc cela devrait être (relativement) facile.

Une explication très simple de la raison pour laquelle ce message tout à fait inutile a été affiché peut exister - les développeurs Linux tapent beaucoup (CLI!) Et n'étant pas très satisfaits de cela, ils ne tapent pas assez pour donner un diagnostic significatif à leurs utilisateurs.

Eh bien, je crois que je n'ai pas raison, mais il doit toujours y avoir une explication pourquoi une telle omission énorme apparaît dans un produit final.

Alexander Christov
la source

De plus, Docker est complètement fonctionnel sans que ce lecteur soit vérifié, tant que vous n'essayez pas de lier-monter un répertoire à partir de votre système de fichiers local. La seule chose est qu'ils veulent suivre les politiques que vous définissez et ne pas les définir pour vous. (Imaginez exécuter un script à l'aveugle qui monte c: \ windows dans le conteneur, puis être surpris lorsque vous trouvez que les hachages de votre compte SAM sont fissurés ... ce qui n'était autorisé que parce qu'ils ont "utilement" coché cette case pour partager le lecteur C et ne l'ont pas fait) t vous en parler.)

sjcaged

retirez la longue commande "docker run ... / dev / null" de la sortie et exécutez-la d'elle-même à l'invite de commande activée par docker. Le bureau Docker devrait alors demander d'autoriser le partage / l'accès au réseau. Vous voudrez peut-être redémarrer l'application Docker Desktop avant de le faire.

Daryl
la source