Docker: l'unità non è stata condivisa

Durante la "dockerizzazione" di un'applicazione MVC ASP.NET Core 3.1 ho ottenuto il seguente risultato:

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 dire che ' docker run --help ' non ha aiutato affatto (collegamenti / ancore mancanti nei documenti Docker ecc.).

Alcune informazioni aggiuntive:

L'applicazione è quella che VS2019 impalcature senza alcuna modifica .
L'immagine Docker è Linux ( che non posso dire ).
La versione Docker è 19.03.5, build 633a0ea

Dal momento che non ho familiarità con Linux, questo errore risulta essere come uno "spettacolo" per me. Forse a Linux non viene richiesto di montare un'unità? Ma quale? Il messaggio non lo dice ...

Forse Windows deve condividere un'unità o mappare una cartella su un'unità che deve essere condivisa? Il messaggio non dice nemmeno questo ...

Ecco uno screenshot della dashboard Docker:

Ed ecco il 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"]

Qualsiasi aiuto sarebbe molto apprezzato. Grazie in anticipo!

docker asp.net-core

— Alexander Christov
fonte

Risposte:

Il comando di esecuzione della finestra mobile include i volumi dall'unità C, ad es -v "C:\Users\admin\vsdbg\vs2017u5:/remote_debugger:rw". Affinché funzionino, è necessario includere l'unità C nelle unità condivise (selezionare la casella in Impostazioni -> Risorse -> Condivisione file). È anche possibile spostare i file da condividere nell'unità D che è già condivisa con la VM incorporata, anche se in questo caso probabilmente non è un'opzione. Per sapere quali unità condividere, controllare le unità utilizzate nei montaggi di volume nel comando Esegui.

Nelle versioni precedenti della finestra mobile per Windows, ciò avrebbe funzionato silenziosamente e avrebbe montato una cartella vuota nel contenitore. Quindi l'errore che dice agli utenti di controllare prima le unità condivise è un bel miglioramento.

— BMitch
fonte

C: è la mia unità di avvio e il sistema operativo è installato su di esso. Pensi davvero che sia una buona pratica condividere informazioni così sensibili?

— Alexander Christov,

@AlexanderChristov l'unità viene condivisa con la VM incorporata che consente di montare le directory da quella nel contenitore. Non puoi dire che non vuoi condividere l'unità mentre vuoi anche eseguire comandi che richiedono l'accesso alle directory su quell'unità. Non si tratta di un problema relativo alla finestra mobile, si tratta di un problema con il comando che si chiede alla finestra mobile di eseguire.

— BMitch

ancora "Vedi 'docker run --help'." è abbastanza inutile. In effetti è un po 'dannoso poiché porta a una pura perdita di tempo, che, come puoi vedere, ha portato a porre la domanda. comunque grazie.

— Alexander Christov,

@AlexanderChristov è un messaggio generico per qualsiasi comando che non riesce, che consente di sapere quale testo della guida del sottocomando può essere pertinente. Non sono sicuro di come regolarlo per coprire ogni possibile condizione di errore. Il 500: {"Message":"Unhandled exception: Drive has not been shared"}messaggio che ha causato l'errore è la parte utile.

— BMitch

Vedi questo per dove / quando generano quel --helpprompt: github.com/moby/moby/blob/…

— BMitch

Rendere l'unità C: disponibile per i contenitori Docker dalla Dashboard Docker risolto il problema , guardare di nuovo l'immagine in cui non è stata verificata.

Un paio di commenti devono essere condivisi IMHO, tuttavia.

Il messaggio di errore non era chiaro quale unità doveva essere condivisa ( suppongo che Linux supporti più di una singola unità )
Se senza rendere l'unità C: disponibile (o l'unità di avvio, quella in cui risiede il sistema operativo) Docker non funzionasse , perché dopo l'installazione non ha controllato l'unità stessa? Questo è solo un clic ( !! ) nella Dashboard Docker, quindi dovrebbe essere (relativamente) facile.

Potrebbe esserci una spiegazione molto semplice del motivo per cui è stato visualizzato questo messaggio abbastanza inutile: gli sviluppatori Linux scrivono molto (CLI!) E non essendo molto contenti di questo, non digitano abbastanza per fornire una diagnostica significativa ai loro utenti.

Bene, credo di non avere ragione, ma ci deve essere una spiegazione del perché un'omissione così grande appare in un prodotto finale.

— Alexander Christov
fonte

Inoltre, Docker è completamente funzionale senza che l'unità sia stata controllata, purché non si stia tentando di eseguire il bind-mount di una directory dal proprio filesystem locale. L'unica cosa è che vogliono seguire le politiche che hai impostato e non impostarle per te. (Immagina di eseguire ciecamente uno script che monta c: \ windows nel contenitore, e quindi di essere sorpreso quando trovi gli hash del tuo account SAM rotti ... il che è stato permesso solo perché hanno "utile" spuntato quella casella per condividere l'unità C e non te lo dico.)

— scritto il

estrarre l'output "docker run ... / dev / null" lungo dall'output ed eseguirlo da solo al prompt dei comandi abilitato docker. Il desktop Docker dovrebbe quindi richiedere di consentire l'accesso alla condivisione / alla rete. Potresti voler riavviare l'app Docker Desktop prima di farlo.

— Daryl
fonte