Crash - Changing data location to larger drive (Using drive space via folder mount point?)

GregDomjan commented 4 years ago

[ ] I have tried with the latest version of my channel (Stable or Edge)
[X] I have uploaded Diagnostics
Diagnostics ID: 106FDD0D-AB87-4460-943F-FE1402A18FA3/20200817104428

Expected behavior

Modified "data-root": to location with more space should be used

Actual behavior

Starting docker with modified "data-root": crashed

Information

Windows Version: Windows 10 1903 (18362.1016)
Docker Desktop Version: 2304 (46911) Stable
Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM: No

Reproducible, new due to configuration change.

In particular, there seems to be some issue relating to the location - a drive mounted to a NTFS folder location rather than being given a separate drive letter. Had been seeing issue with being unable to build images located in same drive space, but moving them out of that space resolved.

unable to prepare context: unable to evaluate symlinks in context path: EvalSymlinks: too many links

Steps to reproduce the behavior

daemon.zip

Mount a drive in an empty folder like c:\data - MS Docs - assign-a-mount-point-folder-path-to-a-drive
Set "data-root": to folder inside the mounted space like "data-root":"C:\\Data\\Docker"
Launch docker desktop
See that Docker folder is created, with tmp and panic.log

tmeckel commented 4 years ago

This not only happens when you set the "data-root" to a disk mounted as a folder, but you simply can't do a docker build in a folder that is mounted as such, regardless if Docker is installed with default settings.

So steps to reproduce:

Mount a drive as folder
Create a folder inside that folder; cd to that folder
Create a Dockerfile. The contents is arbitrary.
Issue docker build -t test .

Version: 2.5.0.0 is affected

docker-robott commented 3 years ago

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

GregDomjan commented 3 years ago

/remove-lifecycle stale

GregDomjan commented 3 years ago

Marking things as stale when the Issue has not been addressed at all seems a bit odd

docker-robott commented 3 years ago

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

GregDomjan commented 3 years ago

/remove-lifecycle stale

docker-robott commented 3 years ago

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

GregDomjan commented 3 years ago

/remove-lifecycle stale

GregDomjan commented 3 years ago

/lifecycle frozen

michha commented 2 years ago

I ran in the same issue. But I can provide a workaround, although a little bit painful.

Lets say we have this setup:

windows machine with 2 disks, one system and one extra drive
the extra drive is mounted via mount point on C:\sometest and the disk itself was labeled TestDisk
your dockerfile and all needed files for docker context are in C:\sometest\docker

Under normal condition we would call inside C:\sometest\docker a simple docker build -f .\Dockerfile . But we get unable to prepare context: unable to evaluate symlinks in context path: EvalSymlinks: too many links. To get around this error we can convert the handsome path into some windows internal path using PowerShell Core:

(Get-Volume -FriendlyName 'TestDisk').Path

This gives us something like \\?\Volume{012345678-abcd-0123-4567-0123456789ab}\. We use this information to call docker build -f '\\?\Volume{012345678-abcd-0123-4567-0123456789ab}\docker\Dockerfile' '\\?\Volume{012345678-abcd-0123-4567-0123456789ab}\docker\'

Suggestion The docker client should do the same logic to prevent the user from getting evolved to this:

test if the path is on a mount point
if so, convert the path to the volume specific path

docker / for-win