VirtioFS is not handling permissions as expected. All mount permissions are owned by root regardless of chown.

[spurin]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: 20220319160755

Expected behavior

Have encountered an issue in VirtioFS. Docker Desktop for Mac should handle bind mounted file permissions as you would expect on a generic Linux distribution. If a bind mount is chown'd to a specific user, it should be visible as being owned by the target user in question.

As an example. If you execute the following with or without the new virtualisation framework and VirtioFS disabled -

% pwd; sudo rm -rf tmphome; mkdir tmphome; docker run --mount type=bind,source=/Users/james/virtiofs-issue/tmphome,target=/home/testuser,bind-propagation=rprivate --rm ubuntu /bin/sh -c "id; useradd -m testuser; chown -R testuser /home/testuser; ls -altrh /home/testuser"
/Users/james/virtiofs-issue
uid=0(root) gid=0(root) groups=0(root)
useradd: warning: the home directory /home/testuser already exists.
useradd: Not copying any file from skel directory into it.
total 4.0K
drwxr-xr-x 2 testuser root   64 Mar 19 15:45 .
drwxr-xr-x 1 root     root 4.0K Mar 19 15:45 ..

The userid of testuser is as expected for the directory ownership.

Actual behavior

If VirtioFS is enabled and Docker Desktop is restarted, and then, the attempt is re-issued, the permissions for that directory are incorrectly owned by root -

% pwd; sudo rm -rf tmphome; mkdir tmphome; docker run --mount type=bind,source=/Users/james/virtiofs-issue/tmphome,target=/home/testuser,bind-propagation=rprivate --rm ubuntu /bin/sh -c "id; useradd -m testuser; chown -R testuser /home/testuser; ls -altrh /home/testuser"
/Users/james/virtiofs-issue
uid=0(root) gid=0(root) groups=0(root)
useradd: warning: the home directory /home/testuser already exists.
useradd: Not copying any file from skel directory into it.
total 4.0K
drwxr-xr-x 2 root root   64 Mar 19 15:51 .
drwxr-xr-x 1 root root 4.0K Mar 19 15:51 ..

For the projects I manage, I make extensive use of users and volumes and at present, this renders the environment unusable owing to the individual userid's having incorrect permissions.

Information

• macOS Version: 12.3
• Intel chip or Apple chip: Apple M1 (Mac Mini)
• Docker Desktop Version: 4.6.0 GA

Output of /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check

Am unsure why the diagnostics are failing but, all is okay when using Docker as per the examples above -

% /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check
Starting diagnostics

[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0031: does the Docker API work?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0011: are the LinuxKit services running?
[FAIL] DD0016: is the LinuxKit VM running? vm is not running: vm has not started
[PASS] DD0001: is the application running?
[PASS] DD0018: does the host support virtualization?
[FAIL] DD0017: can a VM be started? vm has not started: vm has not started
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0007: is the backend responding?
[PASS] DD0014: are the backend processes running?
[PASS] DD0008: is the native API responding?
[PASS] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[PASS] DD0012: is the VM networking working?
[PASS] DD0032: do Docker networks overlap with host IPs?
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0019: is the com.docker.vmnetd process responding?
[PASS] DD0033: does the host have Internet access?

Please investigate the following 1 issue:

1 : The test: can a VM be started?
    Failed with: vm has not started: vm has not started

The Docker engine runs inside a Linux VM. Therefore we must be able to start Virtual Machines.

Steps to reproduce the behavior

1. Disable VirtioFS, run the command example listed, check that the directory is owned by testuser
2. Enable VirtioFS, repeat the test, if the issue occurs the directory is owned by root

[spurin]

Tested on 4.7.0 (76176), issue still persists

[fredericdalleau]

@spurin thanks, we are investigating.
On a side note, could you elaborate a bit on your use case? It seems to me that a volume in the sense of docker volume create could be a better choice as you would have real unix semantics ? Any reason not do so ?

[spurin]

Thanks @fredericdalleau

I very much appreciate you taking the time to respond to this. The environment that I noticed the issue with is open sourced under https://github.com/spurin/diveintoansible-lab

Essentially it provides a nice lab environment allowing those learning Ansible (and Linux in general), to have six vm like containers (ubuntu and centos) and an Ansible control host alongside web terminals and sshd.

I opted for bind mounted directories that correspond to the 'ansible' and 'root' users to cater for those new to unix who at this point, may struggle with the likes of vim or other areas (the course is aimed from a beginner up with no prior knowledge).

With this, all of the user directories are also easily accessible on the host system should they need them.

It the user does have difficulties, they can use a local editor on their system and/or easily copy/save the work they may have done during the course.

If you were curious, you can quickly try the environment on Google Cloud Shell using a standard google id -

https://diveinto.com/p/playground

[jaspertandy]

I'm experiencing this in particular with postgres images where I mount a data dir from host into /var/lib/postgresql/data - the mounted directory gets root ownership, which I can't change. Changing the user in docker-compose.yml does alter the permissions but I still get a lot of permissions errors when trying to write to the database, either by creating databases or inserting data. I'll try to create a replicable docker-compose.yml

Edit: I can't replicate this with a brand new container. Going to try trashing the offending container in my broken project and seeing if that fixes it.

[jaspertandy]

Ah I was just over-thinking it. Given this docker-compose.yml:

version: '3'
services:
  db:
    image: postgres:13.2
    environment:
      POSTGRES_PASSWORD: root
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

Running docker compose up gives me this:

[+] Running 1/1
 ⠿ Container virtio-db-1  Recreated                                                                                                                                                       0.1s
Attaching to virtio-db-1
virtio-db-1  | The files belonging to this database system will be owned by user "postgres".
virtio-db-1  | This user must also own the server process.
virtio-db-1  |
virtio-db-1  | The database cluster will be initialized with locale "en_US.utf8".
virtio-db-1  | The default database encoding has accordingly been set to "UTF8".
virtio-db-1  | The default text search configuration will be set to "english".
virtio-db-1  |
virtio-db-1  | Data page checksums are disabled.
virtio-db-1  |
virtio-db-1  | fixing permissions on existing directory /var/lib/postgresql/data ... ok
virtio-db-1  | creating subdirectories ... ok
virtio-db-1  | selecting dynamic shared memory implementation ... posix
virtio-db-1  | selecting default max_connections ... 100
virtio-db-1  | selecting default shared_buffers ... 128MB
virtio-db-1  | selecting default time zone ... Etc/UTC
virtio-db-1  | creating configuration files ... ok
virtio-db-1  | running bootstrap script ... 2022-03-21 18:07:23.423 UTC [38] LOG:  could not open file "pg_wal/000000010000000000000001": No such file or directory
virtio-db-1  | 2022-03-21 18:07:23.423 UTC [38] FATAL:  could not open file "pg_wal/000000010000000000000001": No such file or directory
virtio-db-1  | child process exited with exit code 1
virtio-db-1  | initdb: removing contents of data directory "/var/lib/postgresql/data"
virtio-db-1 exited with code 1

Presumably because it's trying to do bootstrapping in the postgres container with directories owned by root.

If I change my docker-compose.yml to add a user, I get a different error message:

version: '3'
services:
  db:
    image: postgres:13.2
    user: postgres
    environment:
      POSTGRES_PASSWORD: root
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

[+] Running 1/0
 ⠿ Container virtio-db-1  Created                                                                                                                                                         0.0s
Attaching to virtio-db-1
virtio-db-1  | chmod: changing permissions of '/var/lib/postgresql/data': Operation not permitted
virtio-db-1  | The files belonging to this database system will be owned by user "postgres".
virtio-db-1  | This user must also own the server process.
virtio-db-1  |
virtio-db-1  | The database cluster will be initialized with locale "en_US.utf8".
virtio-db-1  | The default database encoding has accordingly been set to "UTF8".
virtio-db-1  | The default text search configuration will be set to "english".
virtio-db-1  |
virtio-db-1  | Data page checksums are disabled.
virtio-db-1  |
virtio-db-1  | initdb: error: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted
virtio-db-1 exited with code 1

Sorry @spurin for crashing into your issue but I think we're experiencing symptoms of the same problem.

[palgalik]

I think I have the same issue, only this happens with mysql.

My compose file looks like this:

version: '3.5'

services:
  mysql:
    image: mysql/mysql-server:8.0
    volumes:
      - ./data:/var/lib/mysql
    ports:
      - "3306:3306"

My console log:

test-mysql-1  | [Entrypoint] MySQL Docker Image 8.0.28-1.2.7-server
test-mysql-1  | [Entrypoint] Starting MySQL 8.0.28-1.2.7-server
test-mysql-1  | 2022-03-21T20:36:10.700110Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.28) starting as process 1
test-mysql-1  | 2022-03-21T20:36:10.715582Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
test-mysql-1  | 2022-03-21T20:36:10.814497Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
test-mysql-1  | 2022-03-21T20:36:10.848186Z 1 [ERROR] [MY-012585] [InnoDB] Linux Native AIO interface is not supported on this platform. Please check your OS documentation and install appropriate binary of InnoDB.
test-mysql-1  | 2022-03-21T20:36:10.848563Z 1 [Warning] [MY-012654] [InnoDB] Linux Native AIO disabled.
test-mysql-1  | 2022-03-21T20:36:11.162386Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
test-mysql-1  | 2022-03-21T20:36:11.855332Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
test-mysql-1  | 2022-03-21T20:36:11.856044Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
test-mysql-1  | 2022-03-21T20:36:11.860685Z 0 [ERROR] [MY-010259] [Server] Another process with pid 91 is using unix socket file.
test-mysql-1  | 2022-03-21T20:36:11.860827Z 0 [ERROR] [MY-010268] [Server] Unable to setup unix socket lock file.
test-mysql-1  | 2022-03-21T20:36:11.861910Z 0 [ERROR] [MY-010119] [Server] Aborting
test-mysql-1  | 2022-03-21T20:36:12.737014Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.28)  MySQL Community Server - GPL.

Here is my uploaded diagnostics id:
1AFB312E-95AE-48E1-908A-A8E51B0CFD65/20220321202816

[spurin]

No problem by the way @jaspertandy - I welcome your input. We're all in the same boat with this issue 🙂

[doprdele]

I also have this issue. Will upload.

[RikkiMasters]

I also have the issue with MariaDB. Took so long to find that the cause was VirtioFS!

ERROR: 29 File './mysql/' not found (Errcode: 13 "Permission denied")

db:
  image: 'mariadb:10.4.21'
  restart: unless-stopped
  volumes:
    - './docker/mariadb:/var/lib/mysql'

[spurin]

I also have the issue with MariaDB. Took so long to find that the cause was VirtioFS!

ERROR: 29 File './mysql/' not found (Errcode: 13 "Permission denied")

db:

  image: 'mariadb:10.4.21'

  restart: unless-stopped

  volumes:

    - './docker/mariadb:/var/lib/mysql'

Hi @RikkiMasters

Yep, looks like the same issue. Had a look at the Dockerfile for this version of Mariadb and my guess it's also expecting specific user ownership as per the line here -

https://github.com/MariaDB/mariadb-docker/blob/5b93a88ae340de53d621125bef89e3571a325cfa/10.4/Dockerfile#L119

[palgalik]

docker/roadmap#7 (comment)

You can work it around, by adding the following operator to the mysqld command:
command: mysqld --socket=/tmp/mysql.sock

[spurin]

docker/roadmap#7 (comment)

You can work it around, by adding the following operator to the mysqld command:

command: mysqld --socket=/tmp/mysql.sock

Thanks for sharing this workaround for MySQL/MariaDB!

The underline issue of virtiofs not handling permissions as expected is the main context of the issue I raised.

Hopefully when resolved this will resolve the issue I've encountered as well as avoid the need for workarounds or changes to container images like you've had to do 👍

[collettemathieu]

Hi everyone,

I don't know if my issue is the same as yours but I'm encountering a denied permission when using VirtioFS with Docker Desktop 4.6.1 on my macbook M1 pro (version 12.3) and the image node:17.3.

If I try to run yarn install inside the container on my project, I see the following error:

error An unexpected error occurred: "EACCES: permission denied, mkdir '/home/node/app/node_modules/gensync'".

If I disable VirtioFS, I no longer get he error and the command installs the project correctly. If I enable VirtioFS again, the error reappears.

Nevertheless, my file system seems to be correct inside the container because all the files in /home/node/app/ belong to node.

[leonboot]

I'm pretty sure the issue @collettemathieu mentions is related. I'm experiencing the same issue when running composer install, but only when I enter the container as a non-root user. Files in the directory that is volume-mounted to the host filesystem seem to always be owned by whichever user I enter the container with (if I enter it as root, the files are owned by root, if I enter as www-data, the files are owned by www-data). But it seems that changing file attributes (such as permissions, ownership or timestamps) is only permitted by root users. This is the output when I run a composer require command as a non-root user:

www-data@060a93ffd570:/app$ composer require --dev symfony/phpunit-bridge
Info from https://repo.packagist.org: #StandWithUkraine
Using version ^6.0 for symfony/phpunit-bridge
./composer.json has been updated
Running composer update symfony/phpunit-bridge
Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Downloading symfony/phpunit-bridge (v6.0.7)
  - Installing symfony/phpunit-bridge (v6.0.7): Extracting archive
    Install of symfony/phpunit-bridge failed

                                                                                                                                                                     
  [RuntimeException]                                                                                                                                                 
  Failed to extract symfony/phpunit-bridge: (1) '/usr/bin/unzip' -qq '/app/vendor/composer/tmp-8fdfcfea164ee5d9806960b8de20a89f' -d '/app/vendor/composer/aa9c3df7'  
                                                                                                                                                                     
  warning:  cannot set modif./access times for /app/vendor/composer/aa9c3df7/symfony-phpunit-bridge-924f44f/Legacy/                                                  
            Operation not permitted                                                                                                                                  
  warning:  cannot set permissions for /app/vendor/composer/aa9c3df7/symfony-phpunit-bridge-924f44f/Legacy/                                                          
            Operation not permitted                                                                                                                                  
  warning:  set times/attribs failed for /app/vendor/composer/aa9c3df7/symfony-phpunit-bridge-924f44f/Legacy/                                                        
  warning:  cannot set modif./access times for /app/vendor/composer/aa9c3df7/symfony-phpunit-bridge-924f44f/                                                         
            Operation not permitted                                                                                                                                  
  warning:  cannot set permissions for /app/vendor/composer/aa9c3df7/symfony-phpunit-bridge-924f44f/                                                                 
            Operation not permitted                                                                                                                                  
  warning:  set times/attribs failed for /app/vendor/composer/aa9c3df7/symfony-phpunit-bridge-924f44f/                                                               

[t0ny-peng]

I'm seeing the same error while building an internal CMake project. Problem went away if the virtiofs is disabled. As leonboot mentioned, the problem only happens when using a non-root user in the container.

chmod: changing permissions of '<path-to-file>': Operation not permitted

[PascalBrouwers]

This thread is about issues with VirtioFS. Of course disabling it solves the problem...

[Zaszczyk]

Also have this problem with mariadb and percona images.

[PascalBrouwers]

Had some luck running mysql with a different data folder for mysql and using a different socket. Though setting it in my.cnf instead of running mysql with an argument.

Specific lines in my.cnf:

datadir=/var/lib/mysql/data
socket=/var/lib/mysql/mysql.sock

Specific lines in docker-compose.yml:

  mysql:
    volumes:
      - ./var/.mysqldata:/var/lib/mysql/data

[sophos-rickc]

I am seeing what I believe to be the same issue on Docker 4.6.1 on an Intel MBP 16. This always manifests as a permissions issue (e.g., EACCESS). However, I am seeing this not on bind mount volumes, but on named volumes.

This is happening in two different contexts.

1. When installing packages using rush update. This process invokes pnpm install and then creates links from the pnpm packages to each project's node_modules folder. The process that creates the links fails 9 times out of 10. The process is running as node:node, but after the failure, I find dirs/files that have been created by the process with root:root as the owner.
2. When building the app using rush rebuild. This process invokes npm run build for each package. However, the process will fail in a seemingly random project build because it cannot create, rename or delete a file or directory required for the build output.

This all seems to have started late last week. It has gotten worse of the weekend and is no unbearable.

[carflynn2009]

I am also seeing the Issue described here on Docker Desktop for Mac 4.7. I am running a Postgres DB and with virtiofs disabled it comes up ok, as soon as i enable virtiofs i get permission errors of the ownership of var/lib/postgresql/data

FATAL: data directory "/var/lib/postgresql/data" has wrong ownership

setup

event-db:
    image: postgres:alpine
    ports:
      - "5432:5432"
    networks:
      - mynetwork
    environment:
      POSTGRES_USER: eventuser
      POSTGRES_PASSWORD: eventpass
      POSTGRES_DB: event_store
      POSTGRES_HOST_AUTH_METHOD: trust
    container_name: event-db
    volumes:
      - ./postgres-data/event:/var/lib/postgresql/data

[redvex]

Same here with Postgres

[spurin]

Hi @fredericdalleau

Any further thoughts on this? If there's been any progression in the development releases I'll happily test.

Thanks

[nightpool]

Also ran into what appears to be the same issue this morning, would love any workarounds or suggestions people have

[nightpool]

Note: after some investigation, as a workaround i was able to use docker compose run --rm db bash -c 'chown -R postgres $PGDATA/*' to get my postgres container behaving as expected. Absolutely no idea why this should have worked, it seems like a bug, honestly. chown -R postgres $PGDATA did not work.

I have no idea why this would have worked when the Postgres image already tries to do chown -R postgres "$PGDATA" when it starts up.

[ValentineL]

Hello guys.

I have seen so far few attempts to run VirtioFS accelerated directory sharing combined with using Docker services.
Please correct me if I am wrong.

I see in the Docker desktop client in the description saying This improves I/O performance for operations on volumes shared with '-v'.

And in Docker documentation it says:

Based on the above I assume that the VirtioFS accelerated directory sharing is supported only when using containers without services.

I would appreciate your input on this topic.

Thank you.

[blakepettersson]

Here's another reproduction:

1. Clone argoproj/argo-cd
2. Run make test-e2e (make sure k8s is enabled before running this)

This works fine with gRPC FUSE but not with VirtioFS 😞

[benz0li]

Since VirtioFS is enabled by default on macOS 12.5 and above: This issue still persists.

E.g. it also does not work with my JupyterLab docker stacks:

mkdir jupyterlab-benz0li

docker run -it --rm -u root -p 8888:8888 -v "${PWD}/jupyterlab-benz0li":/home/benz0li -e NB_USER=benz0li glcr.b-data.ch/jupyterlab/julia/base:1.9.2

Entered start.sh with args: jupyter lab
/usr/local/bin/start.sh: running hooks in /usr/local/bin/start-notebook.d as uid / gid: 0 / 0
/usr/local/bin/start.sh: running script /usr/local/bin/start-notebook.d/populate.sh
/usr/local/bin/start.sh: done running hooks in /usr/local/bin/start-notebook.d
Updated the jovyan user:
- username: jovyan       -> benz0li
- home dir: /home/jovyan -> /home/benz0li
Populating home dir /home/benz0li...
cp: preserving permissions for ‘/home/benz0li/./.oh-my-zsh/.git/objects/pack/pack-c0618b11380480328642e4e853ae4e4785677879.idx’: Permission denied
cp: preserving permissions for ‘/home/benz0li/./.oh-my-zsh/.git/objects/pack/pack-c0618b11380480328642e4e853ae4e4785677879.pack’: Permission denied
cp: preserving permissions for ‘/home/benz0li/./.oh-my-zsh/.git/objects/pack/pack-c0618b11380480328642e4e853ae4e4785677879.rev’: Permission denied
cp: preserving permissions for ‘/home/benz0li/./.oh-my-zsh/custom/themes/powerlevel10k/.git/objects/pack/pack-b8d7ac91923aba0203a3e1d61906cafe45bbdd4c.idx’: Permission denied
cp: preserving permissions for ‘/home/benz0li/./.oh-my-zsh/custom/themes/powerlevel10k/.git/objects/pack/pack-b8d7ac91923aba0203a3e1d61906cafe45bbdd4c.pack’: Permission denied
cp: preserving permissions for ‘/home/benz0li/./.oh-my-zsh/custom/themes/powerlevel10k/.git/objects/pack/pack-b8d7ac91923aba0203a3e1d61906cafe45bbdd4c.rev’: Permission denied
ERROR: Failed to copy data from /home/jovyan to /home/benz0li!

Populating home dir /home/benz0li... = cp -a /home/jovyan/. /home/benz0li/.

start.sh = https://github.com/b-data/jupyterlab-julia-docker-stack/blob/main/base/scripts/usr/local/bin/start.sh

---

Works fine with gRPC FUSE.

[benz0li]

Works fine with gRPC FUSE.

Inside the container; after cp -a /home/jovyan/. /home/benz0li/ as root; executing ls -al /home/benz0li:

drwxr-xr-x  8 benz0li users   4096 Aug 17 11:32 .
drwxr-xr-x  1 root    root    4096 Sep 12 11:17 ..
-rw-r--r--  1 benz0li users    220 Apr 23 21:23 .bash_logout
-rw-r--r--  1 benz0li users   3646 Aug 26 10:40 .bashrc
drwxr-xr-x  4 benz0li users   4096 Aug 17 11:32 .julia
drwxr-xr-x  4 benz0li users   4096 Aug 17 11:32 .local
drwxr-xr-x 12 benz0li users   4096 Aug 26 10:40 .oh-my-zsh
-rw-r--r--  1 benz0li users  95444 Aug 17 11:32 .p10k.zsh
-rw-r--r--  1 benz0li users    807 Apr 23 21:23 .profile
-rw-r--r--  1 benz0li users   4460 Aug 26 10:40 .zshrc

---

Test: Use -v "${PWD}/jupyterlab-benz0li":/home/benz0li with VirtioFS

Inside the container; after cp -a /home/jovyan/. /home/test/ as root; executing ls -al /home/test:

drwxr-xr-x 10 benz0li users   320 Aug 17 11:32 .
drwxr-xr-x  1 root    root   4096 Sep 12 11:17 ..
-rw-r--r--  1 root    root    220 Apr 23 21:23 .bash_logout
-rw-r--r--  1 root    root   3646 Aug 26 10:40 .bashrc
drwxr-xr-x  3 benz0li users    96 Aug 17 11:32 .julia
drwxr-xr-x  4 benz0li users   128 Aug 17 11:32 .local
drwxr-xr-x 23 benz0li users   736 Aug 26 10:40 .oh-my-zsh
-rw-r--r--  1 root    root  95444 Aug 17 11:32 .p10k.zsh
-rw-r--r--  1 root    root    807 Apr 23 21:23 .profile
-rw-r--r--  1 root    root   4460 Aug 26 10:40 .zshrc

---

P.S.: Inside the container; executing id as benz0li: uid=1000(benz0li) gid=100(users) groups=100(users)

[pkishino]

yeah, no idea why they pushed it as default when this permission issue still persists and now will become even more of a problem for people..

[TargiX]

Just use orbstack if you on apple silicon, its super fast, I waited for these fixes for so long...

[benz0li]

Just use orbstack if you on apple silicon, its super fast, I waited for these fixes for so long...

@TargiX Docker Desktop is just fine and for this issue there is a workaround.

I already use the following alternatives:

• Containers: Podman Desktop
• Virtual Machines: UTM

ℹ️ Both use QEMU in the background.

I have no need for an additional tool.

[tmulle]

Agreed, this is going to break alot of people once they upgrade. I just upgraded to the latest version and the VirtioFS issue broke one of my container startups with the permission error. It was a PostgreSQL container.

Using grpcFuse works just fine and was what I was using because I tried to switch to the VirtioFS before and ran into the same issue.

I reverted back to grpcFuse and things are working on my machine now (M1 MAX Mac 13.5.2)

[martinpeck]

This is a small repo that hits this issue....

echo "Hello Everyone" >> example.txt
sed -i -e "s/Everyone/World/g" example.txt

Under VirtioFS line 2 generates the permission issue
Under gRPC Fuse it's fine.
This is true regardless of running on Intel or Apple Silicon.

Error reported, when run under VirtioFS, is....

sed: couldn't open temporary file ./sedNNaMUc: Permission denied

[markverg]

This is a small repo that hits this issue....

echo "Hello Everyone" >> example.txt
sed -i -e "s/Everyone/World/g" example.txt

Under VirtioFS line 2 generates the permission issue Under gRPC Fuse it's fine. This is true regardless of running on Intel or Apple Silicon.

Error reported, when run under VirtioFS, is....

sed: couldn't open temporary file ./sedNNaMUc: Permission denied

I can confirm, when doing this on a mounted location it gives the error, when running on a non-mounted location it runs fine.

[mike-potter]

This same issue is behind the problem using kubectl within a docker container where you get the error:

open /home/gkh/.kube/config.lock: permission denied

Works fine if I switch to gRPC, but fails when using VirtioFS. If I use orbstack instead of Docker Desktop, it works fine even though OrbStack is also using VirtioFS. Thus, I can only conclude the issue is somewhere with Docker Desktop.

The fact that VirtioFS is now the default for new installs is making this problem more common.

[mcabreb]

I updated to 4.24.0 and though it solved some problems with Rosetta, this VirtioFS problem is still there. It only happens using a container with a shared volume. Using an internal volume is ok.

[james-johnston-thumbtack]

This is still happening for Docker Desktop for Mac version 4.27.1 (136059). In my case even gRPC FUSE is not working.

• File sharing: VirtioFS or gRPC FUSE
• Use Virtualization framework: on

One-line test case, running from macOS host with either VirtioFS or gRPC FUSE:

% docker run -v .:/tmp/testmount -u "$(id -u):$(id -g)" --rm busybox ls -la /tmp
total 8
drwxrwxrwt    1 root     root          4096 Feb  6 23:39 .
drwxr-xr-x    1 root     root          4096 Feb  6 23:39 ..
drwxr-xr-x  120 root     root          3840 Feb  6 22:24 testmount

If I change the file sharing implementation to osxfs (Legacy), then I get the expected result:

% docker run -v .:/tmp/testmount -u "$(id -u):$(id -g)" --rm busybox ls -la /tmp
total 8
drwxrwxrwt    1 root     root          4096 Feb  6 23:45 .
drwxr-xr-x    1 root     root          4096 Feb  6 23:45 ..
drwxr-xr-x  120 502      20            3840 Feb  6 22:24 testmount

Notice that testmount is now owned by 502:20 which is expected as it is the result of $(id -u):$(id -g) on my machine.

We noticed this issue become more pronounced with our recent upgrade to Debian Bookworm, which has the new Git security features that others have mentioned in this thread which enforce consistent ownership throughout the repo.

[silverwind]

Here's some simple steps to reproduce one VirtioFS issue related to socket files:

1. Enable GRPC Fuse in Docker Desktop

2. Run `docker run -it -v ./389:/data '389ds/dirsrv:2.2'`, wait until `389-ds-container started` message appears, then interrupt it

3. Enable VirtioFS in Docker Desktop

4. Run `docker run -it -v ./389:/data '389ds/dirsrv:2.2'`. It should error with

ERR - createprlistensockets - PR_Bind() on localhost file /data/run/slapd-localhost.socket failed: Netscape Portable Runtime error -5968 (TCP-specific function attempted on a non-TCP file descriptor.)

Issue has something to do with permissions of the 389/run/slapd-localhost.socket file which should be srwxr-xr-x but ends up as srw-rw-rw-. This is using v4.20.1.

Re-tested this, works now in v4.28.0.

[benz0li]

Re-tested #6243 (comment) with v4.28.0 v4.29.0: It works now with my JupyterLab docker stacks.

Container startup time:

• gRPC FUSE: 18 seconds
• VirtioFS: 3 seconds

Thank you guys!

[martinpeck]

Sorry...I'm not seeing this as fixed. I've re-run my repro from above. i.e....

echo "Hello Everyone" >> example.txt
sed -i -e "s/Everyone/World/g" example.txt

... and I still see the same permissions error on a mounted drive (and works fine otherwise).

I'm running Docker Desktop v4.29.0 using VirtioFS on MacOS (Intel)

[Smitsel]

Hello!

I'm still also encountering this issue. (We are defaulting to gRPC fuse for now).

Our problem is that we have some containers that use Supervisord and are unable to start due to their inability to create their socket file. Not using Virtio FS solves it, but we prefer to use it due to it's speed.

Did anyone manage to fix this yet?

Update:
I managed to work arround this issue by not letting supervisor use the mounted volume, but instead write to the /tmp folder.

[james-johnston-thumbtack]

I'm sorry, but this issue is still not fixed in my opinion. My test case from #6243 (comment) still fails for VirtioFS and gRPC FUSE. It still only works for osxfs. This is tested (again) on Docker Desktop 4.29.0 (145265) for Mac.

Our organization has a Docker Business account, so I contacted Docker support about this issue. As a starting point, I specifically asked for what the expected behavior of my test case should be based on documented/expected behavior of Docker Desktop.

This was the best I could get, after a month of back-and-forth:

Regarding the behavior for the test case you mentioned on GitHub, it's important to understand that neither VirtioFS nor gRPC FUSE is categorically incorrect. The challenge lies in achieving compatibility across various operating systems, which inherently comes with compromises. gRPC FUSE aims to provide a consistent experience on both Windows and Mac platforms, thereby offering Docker Desktop users a unified experience. This doesn't mean that osxfs's behavior is incorrect; rather, osxfs is only available on Mac and doesn't support some features that gRPC FUSE and VirtioFS do. In essence, the goal is not to mirror Docker Engine on Linux exactly but to balance functionality and compatibility across different environments.

This still leaves me just as confused as before.

This is frustrating, because even basic Git commands will fail security checks when using a Git repo that has been mounted in the manner shown in my test case. One would think that Docker Desktop could work with a mounted Git repo out-of-the-box without hacking up the default configuration of either product, but it is simply no longer the case. We do not want to have to hack around with Git security settings to work around this shortcoming. And as many others have noted on this GitHub issue, it seems a lot of other software is sensitive to this issue as well.

For now, we (unfortunately) feel we must continue using osxfs, since the other options are simply broken when it comes to permissions handling. Our organization is large enough such that we have a large & uncountable number of containers/images, shell scripts, etc. that mount & use Git repos, and they all broke with the new Debian version that has the new Git version with the new security checks on repo file ownership.

[mike-potter]

I'd be interested in knowing if your test case also fails if using OrbStack instead of Docker Desktop. OrbStack also uses VirtioFS but all of our problems went away when we switched to it. If this is also the case with your test then that's more evidence that this is a Docker Desktop issue and not something inherent with VirtioFS.

[Cito]

Had the same experience as @mike-potter. While I had always file permission related problems with gRPC Fuse and VirtioFS in Docker Desktop, OrbStack worked flawlessly for me.

[rittneje]

When can we expect this to be fixed? Running chown within the container usually fixes it, until Docker Desktop inexplicably decides to switch it back to root for no reason.

[rfay]

Docker Desktop 4.35.0 introduces the beta Docker VMM, which seems to solve this longstanding problem!

[nunesvictor]

Docker Desktop 4.35.0 introduces the beta Docker VMM, which seems to solve this longstanding problem!

Can't use Docker VMM, seems always I try add a local folder mapping I got this error

Error response from daemon: error while creating mount source path 'XXX': read-only filesystem