Open maikschulze opened 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
This issue is also present when using Docker Desktop 4.12.0 on Windows 11 22H2.
/remove-lifecycle stale
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
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
I’ve discovered this also, any update on this issue?
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.
It's possible that everyone (including myself) on this gitlab thread is experiencing this as well.
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
/remove-lifecycle stale
/lifecycle frozen
/reopen
Hi @andrea-reale , could you please take a look at this issue and consider reopening it?
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
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
Install Docker Desktop 4.9.1 and switch to Windows containers.
Open a non-administrative Powershell instance and enter a sequence of Docker commands to create data inside a volume:
Restart Docker Desktop.
Continue using the non-administrative Powershell instance to access the volume again:
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.