Docker: Dysk nie został udostępniony

Podczas „dokowania” aplikacji ASP.NET Core 3.1 MVC otrzymałem następujący wynik:

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.

Nie trzeba dodawać, że polecenie „ docker run --help ” wcale nie pomogło (brakujące linki / kotwice w dokumentach Dockera itp.).

Niektóre dodatkowe informacje:

Zastosowanie to rusztowania VS2019 bez żadnych modyfikacji .
Obraz Dockera to Linux ( którego nie mogę powiedzieć ).
Wersja Dockera to 19.03.5, kompilacja 633a0ea

Ponieważ nie jestem zaznajomiony z Linuksem, ten błąd okazuje się dla mnie jak „show-stopper”. Może Linux nie ma instrukcji montowania napędu? Ale który? Wiadomość tego nie mówi ...

Może system Windows musi udostępnić dysk lub zmapować folder na dysk, który należy udostępnić? Wiadomość też tego nie mówi ...

Oto zrzut ekranu pulpitu Docker:

A oto plik 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"]

Każda pomoc będzie mile widziana. Z góry dziękuję!

docker asp.net-core Alexander Christov
źródło

Odpowiedzi:

Polecenie uruchamiania dokera obejmuje woluminy z dysku C, np -v "C:\Users\admin\vsdbg\vs2017u5:/remote_debugger:rw". Aby te działały, musisz dołączyć dysk C do udostępnionych dysków (zaznacz pole w obszarze Ustawienia -> zasoby -> udostępnianie plików). Możesz także przenieść pliki, które mają być udostępnione na dysk D, który jest już udostępniony wbudowanej maszynie wirtualnej, choć w tym przypadku prawdopodobnie nie jest to możliwe. Aby dowiedzieć się, które dyski należy udostępnić, sprawdź dyski używane podczas montowania woluminów w poleceniu uruchomienia.

W poprzednich wersjach okna dokowanego dla systemu Windows po cichu powiodło się i zamontowanie pustego folderu w kontenerze. Błąd informujący użytkowników, aby najpierw sprawdzili udostępnione dyski, jest dobrą poprawą.

BMitch
źródło

C: to mój dysk rozruchowy, na którym jest zainstalowany system operacyjny. Czy naprawdę uważasz, że dobrą praktyką jest dzielenie się tak poufnymi informacjami?

Alexander Christov

@AlexanderChristov dysk zostaje udostępniony wbudowanej maszynie wirtualnej, co pozwala na montowanie katalogów z tego do kontenera. Nie można powiedzieć, że nie chcesz udostępniać dysku, a jednocześnie chcesz uruchamiać polecenia wymagające dostępu do katalogów na tym dysku. To nie jest problem z dokerem, to problem z poleceniem, które chcesz uruchomić.

BMitch

nadal „Zobacz„ Uruchom okno dokowane - pomoc ”.” jest całkiem bezużyteczne. W rzeczywistości jest to nieco szkodliwe, ponieważ prowadzi do czystej straty czasu, co, jak widać, doprowadziło do zadania pytania. w każdym razie dzięki.

Alexander Christov

@AlexanderChristov to ogólny komunikat dla każdego polecenia, które się nie powiedzie, informujący, który tekst pomocy podkomendy może być istotny. Nie wiem, jak to dostosować, aby uwzględnić każdy możliwy błąd. 500: {"Message":"Unhandled exception: Drive has not been shared"}Komunikat, który wywołał błąd jest przydatna część.

BMitch

Zobacz to, gdzie / kiedy generują ten --helpmonit: github.com/moby/moby/blob/…

BMitch

Udostępnienie dysku C: dostępnego dla kontenerów Docker z Docker Dashboard rozwiązało problem , spójrz na zdjęcie jeszcze raz, gdzie nie było zaznaczone.

Kilka komentarzy musi jednak zostać udostępnionych IMHO.

Komunikat o błędzie nie był jasny, który dysk należy udostępnić (chyba Linux obsługuje więcej niż jeden dysk )
Jeśli bez udostępnienia dysku C: (lub dysku rozruchowego, w którym znajduje się system operacyjny) Docker nie działałby , dlaczego po jego instalacji nie sprawdził samego dysku? To tylko jedno kliknięcie ( !! ) w panelu Docker, więc powinno być (względnie) łatwe.

Może istnieć bardzo proste wyjaśnienie, dlaczego wyświetlany był ten zupełnie bezużyteczny komunikat - programiści Linuksa często piszą (CLI!) I nie są z tego powodu bardzo zadowoleni, nie piszą wystarczająco dużo, aby dać sensowną diagnozę swoim użytkownikom.

Cóż, uważam, że nie mam racji, ale wciąż musi być wyjaśnienie, dlaczego tak ogromne pominięcie pojawia się w produkcie końcowym.

Alexander Christov
źródło

Ponadto Docker jest całkowicie funkcjonalny bez sprawdzania tego dysku, o ile nie próbujesz podłączyć katalogu z lokalnego systemu plików. Jedyną rzeczą jest to, że chcą postępować zgodnie z ustalonymi przez Ciebie zasadami, a nie ustawiać je za Ciebie. (Wyobraź sobie, że ślepo uruchamiasz skrypt, który montuje c: \ windows w kontenerze, a potem jesteś zaskoczony, gdy zauważysz, że skróty twojego konta SAM pękają ... co było dozwolone tylko dlatego, że „pomocnie” zaznaczyli to pole, aby udostępnić dysk C i nie o tym wam opowiadać.)

sjcaged

wyciągnij z wyjścia długą komendę „Uruchom okno dokowane ... / dev / null” i uruchom ją samodzielnie w wierszu polecenia włączonym okno dokowane. Pulpit dokera powinien następnie wyświetlić monit o zezwolenie na udostępnianie / dostęp do sieci. Być może będziesz chciał ponownie uruchomić aplikację Docker Desktop.

Daryl
źródło