docker / for-win

Bug reports for Docker Desktop for Windows
https://www.docker.com/products/docker#/windows
1.86k stars 291 forks source link

Volumes broken when using process isolation #12785

Open maikschulze opened 2 years ago

maikschulze commented 2 years ago

Actual behavior

When using process isolation, data stored in volumes becomes inaccessible after a restart of Docker Desktop.

Expected behavior

Data persisted in mounted volumes remains accessible after restarting Docker Desktop.

Information

docker version

Client:
 Cloud integration: v1.0.25
 Version:           20.10.16
 API version:       1.41
 Go version:        go1.17.10
 Git commit:        aa7e414
 Built:             Thu May 12 09:17:07 2022
 OS/Arch:           windows/amd64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.9.1 (81317)
 Engine:
  Version:          20.10.16
  API version:      1.41 (minimum version 1.24)
  Go version:       go1.17.10
  Git commit:       f756502
  Built:            Thu May 12 08:44:17 2022
  OS/Arch:          windows/amd64
  Experimental:     false

This issue does not occur when using HyperV isolation mode.

From my understanding Docker Desktop sets the access rights of data in volumes on startup in a wrong way. The last working version was 4.6.1.

The issue appears to be related to https://github.com/docker/for-win/issues/12701 but is not resolved with the prerelease build here: https://github.com/docker/for-win/issues/12701#issuecomment-1157648786

Steps to reproduce the behavior

  1. Install Docker Desktop 4.9.1 and switch to Windows containers.

  2. Open a non-administrative Powershell instance and enter a sequence of Docker commands to create data inside a volume:

docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:20H2-amd64 powershell -Command mkdir C:/some_volume/foo

    Directory: C:\some_volume

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----         6/17/2022   6:19 AM                foo

docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:20H2-amd64 powershell -Command get-acl C:/some_volume/foo

    Directory: C:\some_volume

Path Owner                               Access
---- -----                               ------
foo  User Manager\ContainerAdministrator NT AUTHORITY\SYSTEM Allow  FullCont...

docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:20H2-amd64 powershell -Command ls C:/some_volume/foo
  1. Restart Docker Desktop.

  2. Continue using the non-administrative Powershell instance to access the volume again:

docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:20H2-amd64 powershell -Command get-acl C:/some_volume/foo

    Directory: C:\some_volume

Path Owner                               Access
---- -----                               ------
foo  User Manager\ContainerAdministrator

docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:20H2-amd64 powershell -Command ls C:/some_volume/foo
ls : Access to the path 'C:\some_volume\foo' is denied.
At line:1 char:1
+ ls C:/some_volume/foo
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (C:\some_volume\foo:String) [G
   et-ChildItem], UnauthorizedAccessException
    + FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.
   Commands.GetChildItemCommand

Personally, I consider this issue very problematic. There is no workaround apart from remaining at Docker 4.6.1. Using hyperv isolation instead of process isolation is not a workable approach, because of open issues related to symlink handling with volumes when using hyperv.

docker-robott commented 2 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

maikschulze commented 2 years ago

This issue is also present when using Docker Desktop 4.12.0 on Windows 11 22H2.

maikschulze commented 2 years ago

/remove-lifecycle stale

docker-robott commented 1 year ago

There hasn't been any activity on this issue for a long time. If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment. If not, this issue will be closed in 30 days.

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

/lifecycle stale

docker-robott commented 1 year ago

Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked

jheaff1 commented 9 months ago

I’ve discovered this also, any update on this issue?

maikschulze commented 9 months ago

I’ve discovered this also, any update on this issue?

I tested with a recent version of Docker Desktop a few months ago. The issue is still present. I therefore switched to bare dockerd.exe which does not show this problem.

solstice333 commented 2 months ago

It's possible that everyone (including myself) on this gitlab thread is experiencing this as well.

maikschulze commented 1 month ago

For what it's worth, the issue persists in today's latest Docker Desktop 4.34.3 (170107).

By now, you would want to test this on Windows 11 the following:

1. Run

docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:ltsc2022 powershell -Command mkdir C:/some_volume/foo

docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:ltsc2022 powershell -Command get-acl C:/some_volume/foo

2. Quit Docker Desktop and stop com.docker.service (Docker Desktop Service)

3. Start Docker Desktop

4. Run

docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:ltsc2022 powershell -Command ls C:/some_volume/foo

docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:ltsc2022 powershell -Command get-acl C:/some_volume/foo

Due to this long-standing issue, step 4 will result in the errors:

C:\Windows\System32>docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:ltsc2022 powershell -Command ls C:/some_volume/foo
ls : Access to the path 'C:\some_volume\foo' is denied.
At line:1 char:1
+ ls C:/some_volume/foo
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (C:\some_volume\foo:String) [G
   et-ChildItem], UnauthorizedAccessException
    + FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.
   Commands.GetChildItemCommand

C:\Windows\System32>docker run --isolation process --rm  --interactive --mount type=volume,src=some_volume,dst=C:/some_volume mcr.microsoft.com/windows/servercore:ltsc2022 powershell -Command get-acl C:/some_volume/foo

    Directory: C:\some_volume

Path Owner                               Access
---- -----                               ------
foo  User Manager\ContainerAdministrator
maikschulze commented 1 month ago

/remove-lifecycle stale

maikschulze commented 1 month ago

/lifecycle frozen

maikschulze commented 1 month ago

/reopen

maikschulze commented 1 month ago

Hi @andrea-reale , could you please take a look at this issue and consider reopening it?