Устранение неполадок при разработке Visual Studio с помощью Docker
При работе со средствами контейнеров Visual Studio могут возникнуть проблемы при сборке или отладке приложения. В этой статье описаны некоторые распространенные действия по устранению неполадок.
Общий доступ к корпоративным данным не включен. Включение совместного использования томов в параметрах Docker CE для Windows (только контейнеры Linux)
Общий доступ к файлам должен управляться только в том случае, если вы используете Hyper-V с Docker. Если вы используете WSL 2, следующие действия не являются обязательными, и параметр общего доступа к файлам не будет отображаться. Чтобы устранить эту проблему, выполните следующие действия:

- Щелкните правой кнопкой мыши Docker для Windows в области уведомлений и выберите Параметры.
- Выберите Ресурсы>Общий доступ к файлам и поделитесь папкой, к которую необходимо получить доступ. Совместное использование всего системного диска возможно, но не рекомендуется.
Visual Studio выводит запрос, если общие диски не настроены.
Не удается запустить отладку
Одна из причин этой проблемы может быть связана с устаревшими компонентами отладки в папке профиля пользователя. Выполните следующие команды, чтобы удалить эти папки, чтобы последние компоненты отладки загружались в следующем сеансе отладки.
- del %userprofile%\vsdbg
- del %userprofile%\onecoremsvsmon
Ошибки, связанные с сетью при отладке приложения
Попробуйте выполнить скрипт, скачанный из раздела Очистка сети узла контейнера, который обновит сетевые компоненты на хост-компьютере.
Отказано в подключении
При использовании Docker для macOS может возникнуть ошибка при ссылке на папку /usr/local/share/dotnet/sdk/NuGetFallbackFolder. Добавьте папку на вкладку Общий доступ к файлам в Docker.
Группа пользователей Docker
При работе с контейнерами в Visual Studio может возникнуть следующая ошибка:
Чтобы использовать Docker Desktop, текущий пользователь должен быть в группе docker-users. Добавьте себя в группу docker-users, а затем выйдите из Windows.
Чтобы иметь разрешения на работу с контейнерами Docker, необходимо быть членом группы docker-users. Чтобы добавить себя в группу в Windows 10 или более поздней версии, выполните следующие действия.
- В меню Пуск откройте раздел Управление компьютером.
- Разверните узел Локальные пользователи и группы и выберите Группы.
- Найдите группу docker-users , щелкните правой кнопкой мыши и выберите Добавить в группу.
- Добавьте учетную запись пользователя или учетные записи.
- Чтобы эти изменения вступили в силу, выйдите из нее и снова войдите в систему.
Вы также можете использовать net localgroup команду в командной строке администратора, чтобы добавить пользователей в определенные группы.
net localgroup docker-users DOMAIN\username /add
В PowerShell используйте функцию Add-LocalGroupMember .
Мало места на диске
По умолчанию Docker хранит образы в папке %ProgramData%/Docker/ , которая обычно находится на системном диске, *C:\ProgramData\Docker*. Чтобы изображения не занимали ценное место на системном диске, можно изменить расположение папки образа. Для этого:
- Щелкните правой кнопкой мыши значок Docker на панели задач и выберите Параметры.
- Выберите Подсистема Docker.
- В области редактирования добавьте graph параметр свойства со значением нужного расположения для образов Docker:
"graph": "D:\\mypath\\images"

Выберите Применить & перезапуск. Эти действия изменяют файл конфигурации по адресу %ProgramData%\docker\config\daemon.json. Ранее созданные образы не перемещаются.
Несоответствие типов контейнера
При добавлении поддержки Docker в проект вы выбираете контейнер Windows или Linux. Если узел Docker Server не настроен для запуска контейнера того же типа, что и целевой объект проекта, появится сообщение об ошибке следующего вида:

Чтобы устранить эту проблему, щелкните правой кнопкой мыши значок Docker для Windows на панели задач и выберите Переключиться на контейнеры Windows. или Переключиться на контейнеры Linux. .
Другие проблемы
Другие проблемы, с которыми вы столкнулись, см. в статье Проблемы с Microsoft/DockerTools .
Ссылки
docker failed to initialize docker desktop is shutting down how can i fixed it [closed]
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago .
This post was edited and submitted for review 2 months ago and failed to reopen the post:
Original close reason(s) were not resolved
I have installed a Docker update version, But I couldn’t open Docker. The Notification is Docker failed to initialize docker desktop is shutting down how can I fixed it.
104k 204 204 gold badges 145 145 silver badges 201 201 bronze badges
asked Oct 6, 2021 at 16:41
Mizanur Rahaman Mizanur Rahaman
423 1 1 gold badge 4 4 silver badges 12 12 bronze badges
Your question talks about Docker, but you do not have a single docker tag and a bunch of seemingly unrelated tags. Please add correct related tags.
Oct 6, 2021 at 16:47
remove all content in C:\Users\
May 1, 2022 at 15:01
Jul 22, 2022 at 8:16
@mkareshky thank you. That should be the answer here in Q3 2022. Fix: Manually remove this file
Sep 9, 2022 at 7:14
remove folder «Docker» in «C:\Users\
Исправление проблем под Docker. Казалось бы, при чём здесь GIT?

Докер под Windows — это постоянные приключения. То ему нужно обновить операционку, иначе последние версии не ставятся, то он забывает, как подключаться к сети. В общем, каждый день от него новости. «Поставил и забыл» — это не про Docker Desktop for Windows. Особенно, когда он используется не совсем так, как рекомендуют его разработчики. А они почему-то не одобряют подключение внешних windows сетевых дисков в качестве локальных. И совсем не одобряют доступ к к таким сетевым папкам, которые расположены ещё и на host машине. Пишут, что это ужас-ужас с точки зрения безопасности, требуют всяких ключей типа:
cap_add:
— SYS_ADMIN
— DAC_READ_SEARCH
для работы команды mount в контейнере и прочая, и прочая.
В общем, когда в очередной раз после выгрузки контейнеров на сервер заказчика сервисы перестали видеть сетевые диски, я не особо удивился. Так уже бывало, и даже была написана пошаговая инструкция для группы поддержки, как и что перезагружать, когда ломаются сетевые настройки докера.
Так что я открываю свою инструкцию и начинаю действовать. Перезапускаю контейнеры — не помогает. Перезапускаю через docker-compose с пересозданием инфраструктуры — не помогает. Сбрасываю настройки Docker к заводским, восстанавливаю параметры виртуалки, загружаю заново образы, запускаю через docker-compose — опять всё по старому — не видит сеть. Точнее не подключается к сетевым шарам, хотя пинг из контейнера до SMB сервера проходит нормально. Последний пункт — перезагрузку сервера и переустановку Docker, пока пропускаю, так как перезагружать сервер очень не хочется. На этом инструкция кончилась.
Ок, перехожу на свою домашнюю машину, тут у меня тоже Docker под Windows, но чуть более новой версии. Проверяю на нём. Те же яйца:

Ага. Ну неужели, думаю, Docker накатил обновление с какой-то безопасностью и теперь мои скрипты из-за этого не запускаются? Последняя проверка — начисто удалить Docker с машины, и поставить заново. Это должно быть круче сброса к заводским настройкам. Проделываю весь перечень из предыдущего шага, только в дополнение к этому ещё и перезагружаю свою машину, чтобы уж совсем железно. Ставлю Docker c нуля, заливаю образы, запускаю docker-compose — ёпрст! Все сервисы как не видели сетевых шар, так и продолжают писать при загрузке «mount error(22): Invalid argument»
Пробую запустить скрипт по строкам из командной строки: подключаюсь к контейнеру, запускаю по очереди команды и вижу, что всё подключается и работает как надо:
mkdir -p $SMB_MOUNT_POINT mount -t cifs $SMB_SHARE $SMB_MOUNT_POINT -o user=$SMB_USER,password=$SMB_PASSWORD,vers=2.0 ls $SMB_MOUNT_POINT
То есть, это что же, какая-то хрень с передачей параметров в скрипт при запуске контейнера?
Ищем ещё идеи. Все варианты с перезагрузкой докера отмели, остались варианты с возможными изменениями в родительском образе. У меня образ собирается на основе openjdk:8-jdk-alpine, конкретной версии не указано, так что какие-нибудь улучшения безопасности могли сломать мои скрипты. Может поменяли что-то в OpenJDK или дочернем Alpine?
Проверяю логи проекта, пробую выбрать более старые openjdk:8-jdk-alpine-3.8, openjdk:8-jdk-alpine-3.7 и т.д. — каждый раз пересобираю контейнер, проверяю — всё по-старому.
Чёрт подери! Может я что-то всё-таки поменял в своей сборке? Выгружаю из GIT’а версию проекта месячной давности, собираю — те же глюки. Трёхмесячной давности — проблема всё ещё тут. Как же так? Что изменилось? Конфигурация докера к настоящему моменту гарантировано рабочая, конфигурация образа — тоже не поменялась, исходники проекта те же самые (GIT всё сохраняет). Чудес не бывает — надо понять, где всё-таки появились изменения. В проде вручную запускаю команды подключения к шарам — так до перезапуска сервисы будут работать нормально и иду спать. Утро вечера мудренее.
Связи нет, но вы держитесь!
Наутро приходит идея — что пора, видимо, узнать, а что собственно говоря не нравится скрипту при выполнении.
Сообщение «mount error(22): Invalid argument» — это не сильно информативно. Нахожу, что есть волшебный ключик -х для баша с которой он выводит отладочную инфу при выполнениии скриптов.
Начинаем отладку внутри sh:
/ # sh -x /entry-point.sh ' echo 'Mount ///Exchange/Pipeline to /pipeline Mount ///Exchange/Pipeline to /pipeline ' mkdir -p '/pipeline ' mount -t cifs ///Exchange/Pipeline /pipeline -o 'user=,password=,vers=2.0 mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) mount: mounting ///Exchange/Pipeline on /pipeline failed: Invalid argument ' ls '/pipeline + exec
И тут появляются какие-то непонятные моменты — строка начинается с кавычек, потом кавычки в конце… Откуда кавычки?
Идея — может запуск с помощью настоящего bash будет информативнее?
Инсталлирую в контейнер BASH:
apk add bash
/ # bash -x /entry-point.sh ' echo 'Mount ///Exchange/Pipeline to /pipeline Mount ///Exchange/Pipeline to /pipeline + mkdir -p $'/pipeline\r' + mount -t cifs ///Exchange/Pipeline /pipeline -o $'user=,password=,vers=2.0\r' mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) mount: mounting ///Exchange/Pipeline on /pipeline failed: Invalid argument + ls $'/pipeline\r' + exec
Блин, тут вроде, когда строка начинается с плюса — это хорошо, но появились какие-то \r и параметры $’. ‘
Ставим Midnight Commander, чтобы уж экспериментировать с удобствами apk add mc и открываем скрипт на редактирование, а там:

Оппа! ^M в конце каждой строки. Ну-ка, ну-ка, смотрим в локальном проекте — а что у нас с окончаниями строк. CRLF. Работаем под Windows, однако.
Меняем в этом конкретно файле CRLF на LF (да здравствует Notepad++!), собираем проект — бинго! Работает как надо.
Почему раньше было ок, а сейчас всё полетело? Смотрю по коммитам — не было никаких перемен. И тут вспоминаю, что GIT умеет на лету править символы перевода строк текстовых файлов. А я на днях подключил новый репозитарий, и возможно выгрузил оттуда все файлы с конвертацией в CRLF.
В итоге добавляем в проект файл .gitattributes, с указанием, что в отдельных файлах надо-таки сохранять символы конца строк как в UNIX:
# Set the default behavior, in case people don't have core.autocrlf set. * text=auto # Declare files that will always have LF line endings on checkout. *.sh text eol=lf
Мораль — иногда виновник даже не попадает в круг первоначальных подозреваемых.
Постскриптум
После обновления на последнюю версию Docker Desktop for Windows 2.2.0.3 всё обратно перестало работать. На этот раз я сразу пошёл внутрь контейнеров, и начал отладку. Оказалось, что перестал работать IP адрес 10.0.75.1 для доступа к хост машине, DockerNat теперь удалён из системы, а виртуалка DockerDesktopVM даже не имеет внешнего сетевого адаптера, т.е. связь с ней идёт не через стандартную сеть, а как-то иначе. И для доступа к хосту надо пользоваться host.docker.internal. Товарищи разработчики так и написали, что
DockerNAT has been removed from Docker Desktop 2.2.0.0 as using an IP address to communicate from the host to a container is not a supported feature. To communicate from a container to the host, you must use the special DNS name host.docker.internal.
Ок, поправил конфиги для тестового окружения, база данных подцепилась, пинг из контейнера до host.docker.internal проходит, а вот сетевые диски не подключаются. Пробую запустить mount вручную из шелла, и получаю знакомую ошибку «mount error(22): Invalid argument».
Убираю по очереди аргументы — запускаю просто «mount -t cifs //host.docker.internal/playground /pipeline» — вроде работает, но стучится от пользователя «root».
Добавляю пользователя: mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser — спрашивает пароль и подключается!
Полный вариант тоже работает:
mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser,password=smbpassword
а вот «mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser,password=smbpassword,vers=2.0» не пашет.
Меняю последний параметр на vers=2.1 — ура, работает!
Похоже, что Docker в последней версии сделал свою собственную имплементацию SMB сервера с блекджеком, но без поддержки 2.0. Ерунда, конечно, по сравнению с другими новостями.
Всем добра, сил и упорства!
Docker failed to initialize Docker Desktop is shutting down — Error in Windows Fixed
![]()
docker failed to initialize docker failed to initialize docker desktop is shutting down docker failed to initialize windows 11 docker failed to initialize windows 10 how to fix docker failed to initialize docker failed to initialize after update docker failed to initialize docker desktop is shutting down docker failed to initialize docker desktop is shutting down windows 11 docker failed to initialize docker desktop is shutting down after update docker failed to initialize docker desktop is shutting down error docker failed to initialize shutting down docker desktop fails to start Deleted settings and locked-directories files but still i get error Deleted Docker and Docker Desktop still getting error how to fix docker desktop failed to start how to see failed docker container logs why is docker failing to start docker desktop is not functioning as expected docker is failing to start docker desktop unable to start The operation has timed out. Docker failed to initialize shutting down windows 11 Docker failed to initialize shutting down windows 10 docker failed to start docker desktop failed to start windows 11 docker desktop failed to start docker desktop is unable to detect a hypervisor how to get rid of docker failed to initialize docker failed to initialize docker failed to run backend processes [SOLVED] Docker Failed to Start Error «Docker Desktop is shutting down» always after the update Docker Failed to Initialize on Windows Why does Docker fail to initialize? How long does it take to start the Docker engine? Why is Docker Desktop data not running?
Показать больше
Войдите , чтобы оставлять комментарии