Длинный рабочий каталог в bash, когда рабочий стол Docker запущен в WSL2
У меня Docker Desktop работает с серверной частью WSL 2. У меня также установлен Ubuntu 20.04 в качестве дистрибутива WSL2 Linux по умолчанию. Проблема, с которой я столкнулся, заключается в том, что если я запускаюC:\Windows\System32\wsl.exe когда Docker запущен, оболочка инициализируется очень длинным путем к каталогу:/mnt/wsl/docker-desktop-bind-mounts/Ubuntu-20.04/8a5edab282632443219e051e4ade2d1d5bbc671c781051bf1437897cbdfea0f1/mnt/c/Windows/System32
Однако, если я выключу докер и снова запущу оболочку WSL, она начнется с ожидаемого пути: /mnt/c/Windows/System32
Я сам могу войти в /mnt/c, но меня раздражает, что он не запускается по правильному пути. Я тоже пробовал бегатьwsl -d "Ubuntu-20.04но безрезультатно. Похоже, что мой том C установлен как на /mnt/c, так и на длинный уродливый путь выше.
Кто-нибудь испытал и решил эту проблему?
Версия докера: 2.3.0.3 (45519)
3 ответа
Кажется, все будет нормально, если я сначала запущу рабочий стол Docker, а затем WSL.
У меня была такая же проблема, и вот что ее исправило:
- Папку, которая монтируется, назовем длинным именем — FL.
- Удалите все контейнеры в Docker, которые связаны с FL
- Перезапустите Докер
- Внутри FL запустите docker-compose, НО не внутри WSL, а на терминале Windows.
- Теперь, когда вы монтируете FL в WSL, запуская команду типа "C:\Windows\System32\wsl.exe -d Ubuntu" - он монтируется с коротким именем.
Подводя итог: проблема для меня заключалась в случайном воссоздании контейнеров Docker внутри папки моего проекта, находящейся в терминале WSL.
Я решил эту проблему, отключив параметр интеграции WSL в настройках Docker в Windows в разделе «Настройки»> «Ресурсы»> «Интеграция с WSL».