Repository navigation
Impossible to remove all virtual file shares #515
Description
Description
Doing some basic security hardening with a new Docker Desktop install, the first thing I did was remove each of the virtual file shares. Or so I thought. Imagine my surprise when the first docker instance I started was still able to write to my home folder!
As it turns out, an empty list is apparently interpreted as "share /Users, /Volumes, /private, /tmp, and /var/folders." The only way to avoid that behavior is to keep one entry in the list.
Reproduce
- Docker Desktop > Settings > Resources > File sharing
- Click the "minus" icon next to each virtual file share.
- Apply & restart
- Quit Docker Desktop
- Start Docker Desktop again. All of the virtual file shares are back.
Expected behavior
It should either save the empty list, or treat an empty list as a validation error. (Preventing me from clicking "Apply & restart.")
docker version
Client:
Version: 28.3.3
API version: 1.51
Go version: go1.24.5
Git commit: 980b856
Built: Fri Jul 25 11:33:03 2025
OS/Arch: darwin/arm64
Context: desktop-linux
Server: Docker Desktop 4.45.0 (203075)
Engine:
Version: 28.3.3
API version: 1.51 (minimum version 1.24)
Go version: go1.24.5
Git commit: bea959c
Built: Fri Jul 25 11:35:32 2025
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.7.27
GitCommit: 05044ec0a9a75232cad458027ca83437aae3f4da
runc:
Version: 1.2.5
GitCommit: v1.2.5-0-g59923ef
docker-init:
Version: 0.19.0
GitCommit: de40ad0docker info
This command outputs personal data.Diagnostics ID
N/A
Additional Info
No response
Activity
mdegans commentedon Jul 9, 2026
I'd like to know whose idea it was to enable this feature by default at all. Spectacularly insecure, dumb, defaults. I can also confirm this bug on macOS 26.5.1 with Docker Desktop v4.81.0. It is not possible to disable these ridiculous shares. I'd like to think whoever came up with this was summarily fired but at Docker that seems unlikely. I think 80% of users are probably unaware of this behavior and would rather it be off by default.
Edit: Workaround: You can remove everything but
/tmpand it sticks. Presumably it requires one entry so you can point it at something empty. Confirmed this works. Now a malicious container can fill up my disk but at least it doesn't have full read+write access to more or less the entire of the machine.ddadon10 commentedon Oct 7, 2026
I just tested on Docker for mac v4.94.0 and this issue seems to have been fixed recently?
I removed all the entries in Virtual file shares in Docker Desktop, and restarted Docker Desktop.
And now I have
cat "$HOME/Library/Group Containers/group.com.docker/settings-store.json" | grep FilesharingDirectoriesreturning"FilesharingDirectories": [],And when I run
docker run --rm --mount type=bind,source=/tmp,target=/probe debian ls -la /probeI have:Anybody else can reproduce the issue?