for-win
for-win copied to clipboard
docker
File browser will only open folders like /et and /var on initial launch of container
Description
Launching a new container like sonarr or ngnix and going to files will allow all folders to be opened/edited. If you navigate away you will no longer be able to open folders like /etc and /var. They will sometimes appear open but if you "close" the folder no amount of restarts will let you open the folder. I have tried 777 the folders to see if it a permission issue to no avail.
Reproduce
- Start a container (something like ngnix)
- Go to files and try to open /etc
- back out to container page (the page that lists all running containers)
- Go back into files for ngnix or container and "close" /etc
- try opening /etc again
Expected behavior
Should open the folder to view files
docker version
Client:
Cloud integration: v1.0.35+desktop.11
Version: 25.0.3
API version: 1.44
Go version: go1.21.6
Git commit: 4debf41
Built: Tue Feb 6 21:13:02 2024
OS/Arch: windows/amd64
Context: default
Server: Docker Desktop 4.28.0 (139021)
Engine:
Version: 25.0.3
API version: 1.44 (minimum version 1.24)
Go version: go1.21.6
Git commit: f417435
Built: Tue Feb 6 21:14:25 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.28
GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client:
Version: 25.0.3
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.12.1-desktop.4
Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe
compose: Docker Compose (Docker Inc.)
Version: v2.24.6-desktop.1
Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe
debug: Get a shell into any image or container. (Docker Inc.)
Version: 0.0.24
Path: C:\Program Files\Docker\cli-plugins\docker-debug.exe
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.0
Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.22
Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.4
Path: C:\Program Files\Docker\cli-plugins\docker-feedback.exe
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.0.1
Path: C:\Program Files\Docker\cli-plugins\docker-init.exe
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe
scout: Docker Scout (Docker Inc.)
Version: v1.5.0
Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe
Server:
Containers: 6
Running: 5
Paused: 0
Stopped: 1
Images: 7
Server Version: 25.0.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
Kernel Version: 5.15.146.1-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 7.44GiB
Name: docker-desktop
ID: 0d4bd3ad-3450-4122-9a61-a917f581d68a
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile
Diagnostics ID
2242E684-F848-4E09-A67D-6051E61A75C8/20240321225625
Additional Info
No response
STR additional details: When this issue happens, click the right arrow icon to the left of the folder (the one you just used earlier) to expand its contents. Notice the folder expands for only 0.1 second before collapsing quickly.
docker info
CPUs: 4
Total Memory: 23.46GiB
ID: 2f772377-d8da-42dd-96d7-0f739dae1533
STR additional details: When this issue happens, click the right arrow icon to the left of the folder (the one you just used earlier) to expand its contents. Notice the folder expands for only 0.1 second before collapsing quickly.
docker info
CPUs: 4 Total Memory: 23.46GiB ID: 2f772377-d8da-42dd-96d7-0f739dae1533
I have tested a few more docker containers and while it doesnt seem to happen to all of them, there are quite a few it does it to. Ngnix is just really bad about it but once it starts, pretty much the only way to fix it is restart docker or restart the PC. I have tried clicking the actual arrow. My thought is maybe it has something to do with a file/folder being written to and changing repeatedly while trying to access it but I have no experience in software coding and thats only a guess XD
Same problem, happened with a very important folder containing my tomcat installation, on multiple containers. It started late last year, I forget which version (thus, upgrading to the latest did not fix it). I have no problems accessing this same folder using command line bash, so I was working around this by copying the files to a new folder, however recently accessing that folder has also stopped working! Additional note: when I restart the container it does allow access - for about 5 minutes, then it starts disallowing access again. Need a fix for this, what could possibly be causing it?
There is a workaround here I found today after fighting with this: https://forums.docker.com/t/issues-using-file-explorer-from-docker-desktop/140926#
To me this screams that Docker's UI thinks that the parent folder is collapsed then you expand it. If you collapse the root folder and work your way back out, the issue is fixed.
There is a workaround here I found today after fighting with this: https://forums.docker.com/t/issues-using-file-explorer-from-docker-desktop/140926#
To me this screams that Docker's UI thinks that the parent folder is collapsed then you expand it. If you collapse the root folder and work your way back out, the issue is fixed.
What if the issue is happening with a folder from the root? Eg: /var
I've been having this issue for many months. The only reliable way for me to open the auto-collapsing folder is with spacebar.
I've been having this issue for many months. The only reliable way for me to open the auto-collapsing folder is with spacebar.
I've been experiencing this lately with the MacOS version of Docker Desktop. Your hint saved me hours of frustration! Thank you for sharing this hint!
Same here. Everytime I wanna do some test quick and dirty changing files it just breaks. UI just does not want to behave.
