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

[spurin]

• [X] I have tried with the latest version of Docker Desktop
• [X] I have tried disabling enabled experimental features
• [X] 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]

https://github.com/docker/roadmap/issues/7#issuecomment-1075945315

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

[spurin]

https://github.com/docker/roadmap/issues/7#issuecomment-1075945315

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.

[nightpool]

@ValentineL i think you're posting in the wrong issue, this bug is for a specific permissions issue that is happening. You may be looking for https://github.com/docker/roadmap/issues/7

[trixn86]

I have the same issue when activating VirtioFS and an existing docker compose setup with postgres:

db:
    image: postgres:11
    restart: always
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_DB=my_project
      - POSTGRES_USER=my_project
      - POSTGRES_PASSWORD=my_project
    volumes:
      - ./data/db:/var/lib/postgresql/data
      - ./build/db:/docker-entrypoint-initdb.d

There already are existing data in ./data/db/ prior to activating VirtioFS.

When doing docker compose up I get:

2022-05-06 13:08:37.272 UTC [1] FATAL:  data directory "/var/lib/postgresql/data" has wrong ownership
2022-05-06 13:08:37.272 UTC [1] HINT:  The server must be started by the user that owns the data directory.

[gordondavies]

Having the same issue with a postgres container mapping to a host volume after activating VirtioFS on MacOS Montery. Turning it off resolves the permissions issue. Similar setup to https://github.com/docker/for-mac/issues/6243#issuecomment-1119600682

MacOS Monterey 12.3.1 (Intel) Docker Desktop 4.8.1 (78998)

[lazcamus]

I'm seeing this bug with git on a virtiofs bind mount of source code into a container for a developer build environment.

Oddly, it's a transient thing:

laz@builder-git_bando ~/git/bando$ git rev-parse HEAD
fatal: unsafe repository ('/Users/laz/git/bando' is owned by someone else)
To add an exception for this directory, call:

    git config --global --add safe.directory /Users/laz/git/bando
laz@builder-git_bando ~/git/bando$ git rev-parse HEAD
234f0a2398902b8131f2e565c0687086c4089440

[ro-kue]

I'm seeing this bug with git on a virtiofs bind mount of source code into a container for a developer build environment.

Oddly, it's a transient thing:

laz@builder-git_bando ~/git/bando$ git rev-parse HEAD
fatal: unsafe repository ('/Users/laz/git/bando' is owned by someone else)
To add an exception for this directory, call:

  git config --global --add safe.directory /Users/laz/git/bando
laz@builder-git_bando ~/git/bando$ git rev-parse HEAD
234f0a2398902b8131f2e565c0687086c4089440

Same issue here. I enabled VirtioFS and opened the container in VSCode and it corrupted the .git directory pretty much right away. Even after recloning the repository.

[cmaddux]

@lazcamus @ro-kue in case helpful with your investigation, we ran into this same issue and have even seen it occasionally with VirtioFS disabled. On our end turns out that it was consistently reproducible with repositories as mounted volumes and linked to git's release addressing CVE-2022-24765. For example, as mentioned in error message - .gitconfig in the container with the following resolves the above git fatal error (and permissions become eventually correct within the mounted volume):

[safe]
directory = "*" # or path to repo in container

(note security implications of above, not necessarily recommending)

I guess still indicates odd permissions handling for mounted volumes (with Virtio disabled for example as soon as we ls within the mounted volume this issue goes away) but on our end possible this permissions behavior of mounted volumes may always have been the case. We just see it now because of this new git release which we hadn't realized came out about a month ago (and maybe exacerbated by enabling Virtio). Hope helpful with your investigation.

[metaskills]

I've run into this issue in a few contexts since trying VirtuoFS. Please please fix.

[desjob]

I'm very excited about the prospect of moving away from NFS based volumes to using virtiofs, but this issue is also blocking me from doing so.

[ilyavaiser]

This issue is also blocking me

[framinlab]

Also having this problem on VirtioFS permissions on Monterey with an M1 Macbook pro.

A CLI downloads and invokes a command inside a container image. The docker run command mounts a folder in the user's home, then invokes a script that asks the user for some input, then goes about doing its thing. Once the container it finishes its thing, it creates a folder in /root/.myfolder and writes some config files into it. Expectation is that the files will be available on the host machine at ~/.myfolder/subfolder.

The command is invoked like this:

docker run -i --mount type=bind,source=~/.myfolder,target=/root/.myfolder ...

This has worked fine in the past. But now, if you run it, you get:

docker: Error response from daemon: invalid mount config for type "bind": stat /host_mnt/private/var/folders/0j/j_j2cydn5kj7xgrqgvknfx340000gs/T/subfolder: permission denied.

The permissions on the mounted folder should remain with the host user so files created there can be accessed locally once the docker image run ends.

Turning off the VirtioFS directory sharing option in Docker Desktop fixes the problem. It sounds like it's similar to other problems being reported here.

[jacobseated]

I'm on MacBook Pro M1, running macOS 12.4 (21F79), and I'm personally considering running everything as root inside the container, just to try and get around this problem, but I am not even sure that would work. Anyone tried it?

[houmanb]

same problem here with VirtioFS enabled

1. Docker Desktop 4.10.1 (82475)
2. MacOS Monterey 12.4 (21F79)

[bagusk99]

I'm using macbook pro 2020 intel base model and MacOS Monterey 12.4, i think i solve this issue to use VirtioFS and postgresql

I'm using docker desktop 4.10.1 (82475)

just try this step and let me know if it's work

1. setting > experimental feature > make sure "enable VirtioFS" and "Use the new Virtualization framework" in unchecked, if "enable VirtioFS" and "Use the new Virtualization framework" is checked we cannot uncheck "use gRPC" in general setting
2. setting > general > uncheck "use gRPC Fuse"
3. apply and restart (in this state docker may shut down, if it happens, just reopen docker desktop)
4. setting > experimental feature > check "enable VirtioFS"
5. apply and restart

and DONE

in the first step we need to make sure to disable "enable VirtioFS" and "Use the new Virtualization framework" because if it enable, "use gRPC Fuse" in general setting will disapear.

i don't know if it's really boost up docker container to 98% like in this article said https://www.docker.com/blog/speed-boost-achievement-unlocked-on-docker-desktop-4-6-for-mac/

but one think i know, the container is much faster now, it's almost feel like it's not in container but native in my host machine.

Note: i use all core of the processor

[wodka]

@bagusk99 tried it and it fails just as before...

[bagusk99]

@wodka this is my settings.json file, i don't know maybe this can help

{ "acceptCanaryUpdates": false, "activeOrganizationName": "", "analyticsEnabled": true, "autoDownloadUpdates": false, "autoStart": false, "backupData": false, "cpus": 8, "credentialHelper": "docker-credential-osxkeychain", "dataFolder": "/Users/{change_this_to_your_mac_user}/Library/Containers/com.docker.docker/Data/vms/0/data", "deprecatedCgroupv1": false, "disableHardwareAcceleration": false, "disableTips": false, "disableUpdate": false, "diskFlush": "os", "diskQcowCompactAfter": 262144, "diskQcowKeepErased": 262144, "diskQcowRuntimeAsserts": false, "diskSizeMiB": 61035, "diskStats": "", "diskTRIM": true, "displayRestartDialog": true, "displayedDeprecate1014": false, "displayedElectronPopup": [], "displayedTutorial": false, "dockerAppLaunchPath": "/Applications/Docker.app", "extensionsEnabled": true, "filesharingDirectories": [ "/tmp", "/Users", "/Volumes", "/private", "/var/folders" ], "firstLaunchTime": 1638871797, "kubernetesEnabled": false, "kubernetesInitialInstallPerformed": false, "lastLoginDate": 0, "latestBannerKey": "", "licenseTermsVersion": 2, "memoryMiB": 2048, "onlyMarketplaceExtensions": false, "openUIOnStartupDisabled": false, "overrideProxyExclude": "", "overrideProxyHttp": "", "overrideProxyHttps": "", "proxyHttpMode": "system", "settingsVersion": 17, "showExtensionsSystemContainers": false, "showKubernetesSystemContainers": false, "socksProxyPort": 0, "swapMiB": 1024, "tipLastId": 0, "tipLastViewedTime": 0, "updateAvailableTime": 0, "updatePopupAppearanceTime": 0, "useCredentialHelper": true, "useNightlyBuildUpdates": false, "useVirtualizationFramework": true, "useVirtualizationFrameworkVirtioFS": true, "useVpnkit": true, "useWindowsContainers": false, "vpnKitAllowedBindAddresses": "0.0.0.0", "vpnKitMTU": 1500, "vpnKitMaxConnections": 2000, "vpnKitMaxPortIdleTime": 300, "vpnKitTransparentProxy": true, "vpnkitCIDR": "192.168.65.0/24", "wslEngineEnabled": false }

EDIT: this file place in "~/Library/Group\ Containers/group.com.docker/settings.json"

[jacobseated]

The solution by @bagusk99 did not work for my MacBook Pro (M1). But, I was just reading about alternative setups, and I think I have some ideas to get around the poor disk i/o, at least in my own case, and others that just wants to work locally on some code.

I guess, instead of mounting directories, I could just transfer my source code into the container and edit the files through an ssh tunnel. This is super easy with an extension in Visual Studio Code, and since it is local, loosing internet is irrelevant.

I am also looking into using Lima and simply creating a full VM for my stuff, or perhaps, using nerdctl instead of docker. I might as well try, because the Docker Containers are running in a VM anyway, and as I read somewhere, the performance issues VirtioFS is intended to solve might be avoided by not mounting stuff on the host?

It seems the solution could be simple if we just need to run a local development environment.

[bagusk99]

I'm really sorry about everyone who cannot use VirtioFS, these are video i recorded with two different project, first using mysql and the second one is using postgresql. i hope these video can help you all.

Laravel (PHP) Mysql

https://user-images.githubusercontent.com/16950268/184055212-4286c398-a510-4e56-a990-1d6cc667d237.mov

Laravel (PHP) Pgsql

https://user-images.githubusercontent.com/16950268/184055296-34294bcf-02fa-4948-a09a-910d307f5b40.mov

This is my macbook type

EDIT: if you have docker network issue just close your docker desktop, open your activity monitor and make sure com.docker.vmnetd already gone. if it's still there just click twice that process and choose quit or force quit and then open docker desktop again

[PascalBrouwers]

Looks like a normal setup with volumes, still won't work with Mysql because of file permission issues when you turn on VirtioFS. Can you share your docker-compose.yml? The video shows almost nothing about it.

[ganey]

@PascalBrouwers I use this for a mysql8 container on m1 mac:

services:
  db8:
    container_name: "db8"
    image: arm64v8/mysql:8-oracle
    ports:
      - 23306:3306
    environment:
      - MYSQL_ROOT_PASSWORD=dev
      - MYSQL_ROOT_HOST=%
      - MYSQL_USER=dev
      - MYSQL_PASSWORD=dev
    volumes:
      - ./data/mysql:/var/lib/mysql
      - ./conf/mysql/conf:/etc/mysql/conf.d

and for mysql 5.7 i roughly use this:

services:
  db:
    container_name: "db"
    build:
      context: conf/mysql
    ports:
      - 3306:3306
    environment:
      - MYSQL_ROOT_PASSWORD=dev
      - MYSQL_ROOT_HOST=%
      - MYSQL_USER=dev
      - MYSQL_PASSWORD=dev
    volumes:
      - ./data/mysql:/var/lib/mysql
      - ./conf/mysql/conf:/etc/mysql
      - ./conf/mysql/initfiles:/docker-entrypoint-initdb.d

for 5.7, the image is based on debian:buster-slim with mysql downloaded from github and built from source

[jaspertandy]

The only difference there for me is the base images, or some other unknown configuration. You're doing volumes in the exact same way I do.

I'm really surprised that Docker isn't responsive here - are we all just doomed to talk about this issue until we lose interest and they can forget about it? I'd be happy to work with Docker to try and diagnose this if it's some sort of legacy configuration issue causing it. Any kind of movement from Docker's side would be nice.

[bagusk99]

Looks like a normal setup with volumes, still won't work with Mysql because of file permission issues when you turn on VirtioFS. Can you share your docker-compose.yml? The video shows almost nothing about it.

sorry about that this is my docker-compose.yml

----> Mysql Project

version: '3'
services:

  #Redis Service
  basset-redis:
    image: redis:5.0-alpine
    container_name: basset-redis
    restart: unless-stopped
    tty: true
    ports:
      - "63792:6379"
    volumes:
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
      - redisdata:/data
    networks:
      - basset-network

  #PHP Service
  basset-app:
    build:
      context: .
      dockerfile: Dockerfile
    image: laravel
    container_name: basset-app
    restart: unless-stopped
    tty: true
    environment:
      SERVICE_NAME: app
      SERVICE_TAGS: dev
    working_dir: /var/www
    volumes:
      - ./:/var/www
      - ./php/local.ini:/usr/local/etc/php/conf.d/local.ini
    networks:
      - basset-network

  #Nginx Service
  basset-webserver:
    image: nginx:alpine
    container_name: basset-webserver
    restart: unless-stopped
    tty: true
    ports:
      - "8082:80"
      - "4432:443"
    volumes:
      - ./:/var/www
      - ./nginx/conf.d/:/etc/nginx/conf.d/
    networks:
      - basset-network

  #MySQL Service
  basset-db:
    image: mysql:5.7.22
    container_name: basset-db
    restart: unless-stopped
    tty: true
    ports:
      - "33063:3306"
    environment:
      MYSQL_DATABASE: basset_db2022
      MYSQL_ROOT_PASSWORD: basset_db2022
      SERVICE_TAGS: dev
      SERVICE_NAME: mysql
    volumes:
      - ./database/basset.sql:/home/basset.sql
      - dbdata:/var/lib/mysql/
      - ./mysql/my.cnf:/etc/mysql/my.cnf
    networks:
      - basset-network

#Docker Networks
networks:
  basset-network:
    driver: bridge
#Volumes
volumes:
  dbdata:
    driver: local
  redisdata:
    driver: local

----> Pgsql Project

version: "3.8"

networks:
  frontend:
    driver: ${NETWORKS_DRIVER}
  backend:
    driver: ${NETWORKS_DRIVER}

volumes:
  postgres:
    driver: ${VOLUMES_DRIVER}
  redis:
    driver: ${VOLUMES_DRIVER}

services:
  core:
    build:
      context: docker/image
      args:
        - USER_CONTAINER=${USER_CONTAINER}
        - PUID=${PUID}
        - PGID=${PGID}
    restart: unless-stopped
    depends_on:
      - db
      - redis
    volumes:
      # laravel comes up with public dir inside workdir, so we will mount only /var/www
      - ./:/var/www
    ports:
      - ${APP_DOCK_PORT}:80
    networks:
      - frontend
      - backend
  db:
    image: timescale/timescaledb:2.1.0-pg13
    volumes:
      - ${DATA_PATH_HOST}/postgres:/var/lib/postgresql/data
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${DB_DATABASE}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    networks:
      - backend
  redis:
    image: redis
    restart: unless-stopped
    volumes:
      - ${DATA_PATH_HOST}/redis:/data
    networks:
      - backend
  scheduler:
    image: ghcr.io/digital-entropy/dokar-php/cli:8.0
    restart: unless-stopped
    depends_on:
      - db
      - redis
    volumes:
      - ./:/var/www
      - ./docker/config/scheduler/:/entrypoint.d
    networks:
      - backend
    environment:
      - USER=${USER_CONTAINER}
      - PUID=${PUID}
      - PGID=${PGID}
    working_dir: /var/www
    entrypoint: [ /entrypoint.d/entrypoint.sh ]
  horizon:
    image: ghcr.io/digital-entropy/dokar-php/cli:8.0
    restart: unless-stopped
    depends_on:
      - db
      - redis
    volumes:
      - ./:/var/www
      - ./docker/config/horizon/:/entrypoint.d
    networks:
      - backend
    environment:
      - USER=${USER_CONTAINER}
      - PUID=${PUID}
      - PGID=${PGID}
    working_dir: /var/www
    entrypoint: [ /entrypoint.d/entrypoint.sh ]
  mailhog:
    image: mailhog/mailhog
    ports:
      - 8025:8025
    networks:
      - frontend
  soketi:
    image: 'quay.io/soketi/soketi:latest-16-alpine'
    environment:
        SOKETI_DEBUG: '1'
        SOKETI_METRICS_SERVER_PORT: '9601'
    ports:
        - '${SOKETI_PORT:-6001}:6001'
        - '${SOKETI_METRICS_SERVER_PORT:-9601}:9601'
    networks:
        - backend

[richterd]

Hi folks, I solved this problem by switching from bind mount to a docker volume (see here for more information: Docker Volumes)

You can do the following to switch:

1. Backup your database
2. Change your docker compose as follows (this example only shows the changes, the volume name can be whatever you prefer, but has to be unique within your docker installation):

#OLD
services:
  db:
    volumes:
      - ./db:/var/lib/mysql

#NEW
volumes:
  my_db_data:
services:
  db:
    volumes:  
      - my_db_data:/var/lib/mysql

3. Restore your database
4. Enjoy :)

[jaspertandy]

That's not a long term solution - it essentially removes the ability to use an entire feature of Docker.

[carflynn2009]

Hi folks, I solved this problem by switching from bind mount to a docker volume (see here for more information: Docker Volumes)

You can do the following to switch:

1. Backup your database
2. Change your docker compose as follows (this example only shows the changes, the volume name can be whatever you prefer, but has to be unique within your docker installation):

#OLD
services:
  db:
    volumes:
      ./db:/var/lib/mysql

#NEW
volumes:
  my_db_data:
services:
  db:
    volumes:  
      my_db_data:/var/lib/mysql

3. Restore your database
4. Enjoy :)

I can confirm this fixed the issue for me

[tewarid]

I am also seeing the issue with tar, and perhaps with sed -i where file permissions (exec in particular) are not copied over

$ echo "world" > hello
$ sed -i.old -e '/world/ s/world/hello world/' hello
$ ls -l hello*
-rw-------+ 1 yoctouser yoctouser 12 Sep 13 11:51 hello
-rw-r--r--  1 yoctouser yoctouser  6 Sep 13 11:51 hello.old

I want to use case-sensitive volume and bind mount to build yocto project builds, and this issue is a show stopper for now.