Permissions issue with VirtioFS

abentele commented 1 year ago

[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:

Summary / Steps to reproduce

I started a gitlab container with docker compose. This container has a volume:

<some-local-folder>:/var/opt/gitlab:cached

what I did in the running container (note the commands access a sub-folder of the volume):

chmod 2770 /var/opt/gitlab/git-data/repositories
stat --printf='%04a' $(readlink -f /var/opt/gitlab/git-data/repositories) | grep -o '....$'

Expected behavior

I would expect the permissions of this folder are as set by the chmod command before:

Therefore the output of the stat command should be:

Actual behavior

output of the stat command with setting "gRPC FUSE" of Docker Desktop (this is ok):

output of the stat command with setting "VirtioFS" of Docker Desktop (this is wrong!):

Btw.: gitlab fails on startup because of this issue.

Information

The problem should be reproducible with any other container. The problem is since I switched my settings to VirtioFS. With setting gRPC FUSE it works.

macOS Version: 13.0.1
Intel chip or Apple chip: Intel
Docker Desktop Version: 4.15.0 (93002)

Output of `/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] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0014: are the backend processes running?
[PASS] DD0007: is the backend responding?
[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?
[SKIP] DD0030: is the image access management authorized?
[FAIL] DD0019: is the com.docker.vmnetd process responding? failed to ping vmnetd with error: failed to connect to /var/run/com.docker.vmnetd.sock: is vmnetd running?: dial unix /var/run/com.docker.vmnetd.sock: connect: no such file or directory
[PASS] DD0033: does the host have Internet access?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0032: do Docker networks overlap with host IPs?

Please investigate the following 1 issue:

1 : The test: is the com.docker.vmnetd process responding?
    Failed with: failed to ping vmnetd with error: failed to connect to /var/run/com.docker.vmnetd.sock: is vmnetd running?: dial unix /var/run/com.docker.vmnetd.sock: connect: no such file or directory

The com.docker.vmnetd process is needed to create symlinks for CLIs in your path.

Steps to reproduce the behavior

See above.

niccolomineo commented 1 year ago

Still testing this, but might be related to what the OP is experiencing: since updating to 4.15, when I git pull the files are set to 755 instead of 644. My umask seems to be defaulting to what I expect (0022). I don't seem to have any problems with the other virtualization modes available.

thaJeztah commented 1 year ago

Thanks for reporting; I just hit this issue myself; I'm discussing with the team working on VirtioFS, and they're looking into it.

fasmat commented 1 year ago

Same here. For some reason all files inside my devcontainer are now marked as executable after a git pull.

bramru commented 1 year ago

Same here, rolling back to 4.14.1 solves the problem

thaJeztah commented 1 year ago

Short update; I see a patch is being worked on to fix this (but not finished yet); from the description, it looks like there may be a bug on Apple's side, but we're looking at a workaround until that's fixed.

markeissler commented 1 year ago

I can also confirm this issue. It's really creating havoc while working in a VSCode devcontainer. Files randomly reset their permissions from 0644 to 0755 in the container. Then if try to run a git status in the host OS (macOS Monterey) git thinks ALL of the files have changed (or a ton of them) and a git diff indicates that the permissions have changed (from 0755 to 0644). This might be impacting my ability to rebase as well but not sure.

markeissler commented 1 year ago

Switched back to "gRPC FUSE" for now. Seems like a good enough work around until a fix is in place.

fredericdalleau commented 1 year ago

Hey there, this build no longer sets the executable bit on your volume files : amd64: https://desktop-stage.docker.com/mac/main/amd64/94201/Docker.dmg arm64: https://desktop-stage.docker.com/mac/main/arm64/94201/Docker.dmg Let us know if any issue occurs, Thanks!

fredericdalleau commented 1 year ago

@abentele note that this executable bit issue is different for the issue you're facing. Investigation continues.

oinopion commented 1 year ago

@fredericdalleau my team experienced the same problem with permissions in dev container on 4.15. The build that you've linked resolves the problem for us 👍

Is this likely to be released soon?

fredericdalleau commented 1 year ago

@oinopion thanks for feedback, it should land in our next release early next year

umbrellait-danil-rodin commented 1 year ago

@fredericdalleau Thanks a lot for this Docker build!

niccolomineo commented 1 year ago

4.16 preview works like a charm on my system, thank you for that. 👍

mat007 commented 1 year ago

Closing this issue because a fix has been released in Docker Desktop 4.16. See the release notes for more details.

pirog commented 1 year ago

Sadly we are still having issues with 4.16.1 over at https://github.com/lando/lando which is unfortunate because our users definitely crave being able to use VirtioFS.

4.16.1 produces breaking behavior because it does not mount our boot up entrypoint scripts with the same permissions they have on the host.

This is what the perms look like for our scripts. Is this intentional?

total 544
     0 drwxr-xr-x  134 501      dialout       4288 Nov 18 19:53 .
     4 drwxr-xr-x    1 root     root          4096 Jan 13 18:15 ..
     8 -rwxr-xr-x    1 501      dialout       6148 Oct 26  2021 .DS_Store
     4 -------r--    1 501      dialout       1248 May  6  2020 999-proxy-certs.sh
     4 -------r--    1 501      dialout        811 Jan 13 18:15 acquia-clone.sh
     4 -------r--    1 501      dialout        242 Jan 13 18:15 acquia-config-symlink.sh
     4 -------r--    1 501      dialout        322 Jan 13 18:15 acquia-generate-key.sh
     4 -------r--    1 501      dialout       1188 Mar 17  2021 acquia-get-remote-url.sh
     4 -------r--    1 501      dialout       3152 Jan 13 18:15 acquia-pull.sh
     4 -------r--    1 501      dialout       2087 Jan 13 18:15 acquia-push.sh
     4 -------r--    1 501      dialout        509 Mar 13  2021 acquia-settings.inc
     8 -------r--    1 501      dialout       4319 Jan 13 18:15 add-cert.sh
     4 -------r--    1 501      dialout       2920 Sep 15  2021 agent.sh
     4 -------r--    1 501      dialout       1456 Jan 13 18:15 auth.sh
...

jalaziz commented 1 year ago

Can confirm issues with 4.16.1 as well.

We're building protobuf files on a host-mounted volume which results in temp files with no permissions (which ultimately leads to a proto build failure):

---------- 1 jalaziz staff     0 Jan 15 02:10 sednOBSOT

fredericdalleau commented 1 year ago

@pirog, can you share what command you used to get this result?

pirog commented 1 year ago

@fredericdalleau sadly i cannot!

I reset Docker Desktop to factory defaults and rebooted my computer and now it seems to work as expected. At least for me. Does that make any sense to you?

fredericdalleau commented 1 year ago

You may need to reenable virtiofs as it not default. If it happens again, you can try on the host : xattr -l <filename> and see there is any output. If so you can clear it with xattr -c <filename>, and set the permissions again. (and share the output here)

pirog commented 1 year ago

@fredericdalleau good to know.

We have some users reporting the same initial no-perms behavior so i'm going to walk through it with a few of them and hopefully i'll be able to track things down a bit better for you all.

renkosteenbeek commented 1 year ago

I've got this issue too, so I've to downgrade to 3.15 which works, even with VirtioFS enabled. On 3.16.x it breaks when using VirtioFS.

Using Apple Silicon.

xEtherealx commented 1 year ago

On 4.16.2 and also seeing this issue; Mac pro with Intel chip. It's amazing that this feature isn't still in the "Features in development" section! Permissions is a massively important thing to get right.

Lmk if you'd like a set of repro steps (although fair warning; it's not a simple setup)

fredericdalleau commented 1 year ago

@xEtherealx Thanks for reporting, can you share share your reproduction steps? For a complex setup, it would be very kind to prepare a git repo with a script or docker compose file.

xEtherealx commented 1 year ago

@fredericdalleau it's not a super complex setup actually, just a bit time consuming because the build process is lengthy. Here are the repro steps:

Clone this fork of batocera.linux, with the osxsupport branch which adds the ability to kick off build on OSX https://github.com/xEtherealx/batocera.linux/tree/osxsupport
Make sure that virtiofs is enable in docker desktop
in the root directory, run make build-docker-image and then once the docker image is built, make V=1 bcm2837-build

That's it, the build may take a while but results in weird permissions issues reliably for me

fredericdalleau commented 1 year ago

@xEtherealx An error occurs : No rule to make target batocera-bcm2837_defconfig. It also occurs on Linux host on master branch.

thomas-schwieters commented 1 year ago

Hello,

I also have this behaviour. I recently switched with my smarthome from Ubuntu (with Docker) to Mac OS with Docker. I am having issues with VirtioFS with GitLab and with Nodered.

I know how to reproduce this problem.

Use this docker-compose file

version: "2.4"
services:
        nodered:
                image: nodered/node-red:latest
                ports: 
                        - 1881:1880
                volumes:
                        - /Users/username/Docker/Volumes/nodered_test:/data
                restart: unless-stopped
        %

Then access nodered via browser http://localhost:1881 Click on the top right, then settings -> palette -> install. Search for node-red-dashboard and try to install it. It will abort with an error message. As soon, as you switch back to gRPC FUSE the installation will work fine. Also it's not for all nodered modules, but definitely for this one

-----------------------------------------------------------
2023-02-08T10:32:16.552Z Install : node-red-dashboard 3.3.1

2023-02-08T10:32:16.567Z npm install --no-audit --no-update-notifier --no-fund --save --save-prefix=~ --production --engine-strict node-red-dashboard@3.3.1
2023-02-08T10:32:16.868Z [err] npm
2023-02-08T10:32:16.868Z [err]  WARN config production Use `--omit=dev` instead.
2023-02-08T10:32:17.788Z [err] npm WARN tarball tarball data for ms@https://registry.npmjs.org/ms/-/ms-2.1.2.tgz (sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==) seems to be corrupted. Trying again.
2023-02-08T10:32:17.790Z [err] npm WARN
2023-02-08T10:32:17.790Z [err]  tarball tarball data for ms@https://registry.npmjs.org/ms/-/ms-2.1.2.tgz (sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==) seems to be corrupted. Trying again.
2023-02-08T10:32:17.848Z [err] npm WARN tarball tarball data for debug@https://registry.npmjs.org/debug/-/debug-4.3.4.tgz (sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==) seems to be corrupted. Trying again.
2023-02-08T10:32:17.852Z [err] npm WARN tarball tarball data for debug@https://registry.npmjs.org/debug/-/debug-4.3.4.tgz (sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==) seems to be corrupted. Trying again.
2023-02-08T10:32:17.888Z [err] npm WARN tarball tarball data for ms@https://registry.npmjs.org/ms/-/ms-2.1.2.tgz (sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==) seems to be corrupted. Trying again.
2023-02-08T10:32:17.892Z [err] npm WARN tarball tarball data for ms@https://registry.npmjs.org/ms/-/ms-2.1.2.tgz (sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==) seems to be corrupted. Trying again.
2023-02-08T10:32:17.938Z [err] npm WARN tarball tarball data for debug@https://registry.npmjs.org/debug/-/debug-4.3.4.tgz (sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==) seems to be corrupted. Trying again.
2023-02-08T10:32:17.939Z [err] npm WARN 
2023-02-08T10:32:17.939Z [err] tarball tarball data for debug@https://registry.npmjs.org/debug/-/debug-4.3.4.tgz (sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==) seems to be corrupted. Trying again.
2023-02-08T10:32:18.768Z [err] npm ERR! code ENOENT
2023-02-08T10:32:18.768Z [err] npm ERR! syscall lstat
2023-02-08T10:32:18.768Z [err] npm ERR! path /data/.npm/_cacache/content-v2/sha512/3d/15/851ee494dde0ed4093ef9cd63b25c91eb758f4b793ae3ac1733cfcec7a40f9d9997ca947c520f122b305ea22f1d61951ce817fbb1bfbc234d85e870c5f91
2023-02-08T10:32:18.769Z [err] npm ERR! errno -2
2023-02-08T10:32:18.769Z [err] npm ERR! enoent ENOENT: no such file or directory, lstat '/data/.npm/_cacache/content-v2/sha512/3d/15/851ee494dde0ed4093ef9cd63b25c91eb758f4b793ae3ac1733cfcec7a40f9d9997ca947c520f122b305ea22f1d61951ce817fbb1bfbc234d85e870c5f91'
2023-02-08T10:32:18.770Z [err] npm ERR! enoent This is related to npm not being able to find a file.
2023-02-08T10:32:18.770Z [err] npm ERR! enoent 
2023-02-08T10:32:18.773Z [err] 
2023-02-08T10:32:18.774Z [err] npm ERR! A complete log of this run can be found in:
2023-02-08T10:32:18.774Z [err] npm ERR!     /data/.npm/_logs/2023-02-08T10_32_16_843Z-debug-0.log
2023-02-08T10:32:18.804Z rc=254

fredericdalleau commented 1 year ago

@thomas-schwieters could it relate to a long path? Could you try with a shorter volume path ?

                        - /Users/username/nodest:/data

thomas-schwieters commented 1 year ago

I just tried it with this path:

                volumes:
                        - /Users/thomasschwieters/nodered:/data

Same error:

thomasschwieters-nodered-1  | Your flow credentials file is encrypted using a system-generated key.
thomasschwieters-nodered-1  | 
thomasschwieters-nodered-1  | If the system-generated key is lost for any reason, your credentials
thomasschwieters-nodered-1  | file will not be recoverable, you will have to delete it and re-enter
thomasschwieters-nodered-1  | your credentials.
thomasschwieters-nodered-1  | 
thomasschwieters-nodered-1  | You should set your own key using the 'credentialSecret' option in
thomasschwieters-nodered-1  | your settings file. Node-RED will then re-encrypt your credentials
thomasschwieters-nodered-1  | file using your chosen key the next time you deploy a change.
thomasschwieters-nodered-1  | ---------------------------------------------------------------------
thomasschwieters-nodered-1  | 
thomasschwieters-nodered-1  | 9 Feb 14:08:36 - [info] Server now running at http://127.0.0.1:1880/
thomasschwieters-nodered-1  | 9 Feb 14:08:36 - [warn] Encrypted credentials not found
thomasschwieters-nodered-1  | 9 Feb 14:08:36 - [info] Starting flows
thomasschwieters-nodered-1  | 9 Feb 14:08:36 - [info] Started flows
thomasschwieters-nodered-1  | 9 Feb 14:09:18 - [info] Installing module: node-red-dashboard, version: 3.3.1
thomasschwieters-nodered-1  | 9 Feb 14:09:20 - [warn] Installation of module node-red-dashboard failed:
thomasschwieters-nodered-1  | 9 Feb 14:09:20 - [warn] ------------------------------------------
thomasschwieters-nodered-1  | 9 Feb 14:09:20 - [warn] npm WARN config production Use `--omit=dev` instead.
thomasschwieters-nodered-1  | npm ERR! code ENOENT
thomasschwieters-nodered-1  | npm ERR! syscall rename
thomasschwieters-nodered-1  | npm ERR! path /data/.npm/_cacache/tmp/07005d37
thomasschwieters-nodered-1  | npm ERR! dest /data/.npm/_cacache/content-v2/sha512/49/df/a5a5e22482b4bae15832f900fe23bcbae5ed60665f85dd2f0c10ef05b9e47df28b0c7a479de5651e6a60052838ff4db5291bf1eddbec925a611953b34d91
thomasschwieters-nodered-1  | npm ERR! errno ENOENT
thomasschwieters-nodered-1  | npm ERR! enoent Invalid response body while trying to fetch https://registry.npmjs.org/debug: ENOENT: no such file or directory, rename '/data/.npm/_cacache/tmp/07005d37' -> '/data/.npm/_cacache/content-v2/sha512/49/df/a5a5e22482b4bae15832f900fe23bcbae5ed60665f85dd2f0c10ef05b9e47df28b0c7a479de5651e6a60052838ff4db5291bf1eddbec925a611953b34d91'
thomasschwieters-nodered-1  | npm ERR! enoent This is related to npm not being able to find a file.
thomasschwieters-nodered-1  | npm ERR! enoent 
thomasschwieters-nodered-1  | 
thomasschwieters-nodered-1  | npm ERR! A complete log of this run can be found in:
thomasschwieters-nodered-1  | npm ERR!     /data/.npm/_logs/2023-02-09T14_09_18_402Z-debug-0.log
thomasschwieters-nodered-1  | 
thomasschwieters-nodered-1  | 9 Feb 14:09:20 - [warn] ------------------------------------------
thomasschwieters-nodered-1  | Error: Install failed
thomasschwieters-nodered-1  |     at /usr/src/node-red/node_modules/@node-red/registry/lib/installer.js:285:25
thomasschwieters-nodered-1  |     at processTicksAndRejections (node:internal/process/task_queues:96:5)
thomasschwieters-nodered-1  | 9 Feb 14:09:20 - [error] Error: Install failed
thomasschwieters-nodered-1  | 9 Feb 14:10:03 - [info] Stopping flows
thomasschwieters-nodered-1  | 9 Feb 14:10:03 - [info] Stopped flows

fredericdalleau commented 1 year ago

@thomas-schwieters do you have a curl request that could be used after starting the container that triggers the error?

thomas-schwieters commented 1 year ago

No, I don't have the curl command, but you can execute this command inside the container:

npm install --no-audit --no-update-notifier --no-fund --save --save-prefix=~ --production --engine-strict node-red-dashboard@3.3.1

rasika-jay commented 1 year ago

I'm running a container built on top of ubuntu:22.04 base image on an intel mac (13.2). I'm also mounting some volumes to an external drive formatted using exfat to the same container.

With virtiofs, sometimes writes/creating directories/files fails. Switching back to GRPC Fuse works. I'm running Docker Deskop 16.2.

xEtherealx commented 1 year ago

@fredericdalleau sorry I wasn't super clear -- the build commands need to be run in the host (within the mounted directory) and the first creates the image, the second executes the build within the container. Does that resolve your issue?

fredericdalleau commented 1 year ago

@xEtherealx the first command succeeds, the second fails with that error. make V=1 bmc2837-config also fails with the same error. Is batocera-bcm2837_defconfig in the right place?

fredericdalleau commented 1 year ago

@thomas-schwieters we tried an arm mac running mac OS Ventura and it worked. An Intel mac running macOS 12.5.1 reproduced the error. What OS architecture and version do you run?

thomas-schwieters commented 1 year ago

that is really strange. I am running a Mac mini M1 2020 with Ventura 13.2 (Docker Engine v20.10.22). It's really strange, because the error appears always for me. When I delete the folder and try again from scratch, it's the same issue. I also have a MacBook Air M1, I can try to reproduce on that machine.

thomas-schwieters commented 1 year ago

I just tried from my MacBook. Same issue, see screenshot.

thomas-schwieters commented 1 year ago

Hmm, on my MacBook Air it seems to be a different error message. But anyhow, it's related to VirtioFS, because as soon as I switch to gRPC Fuse, the command works

nulllpoint commented 1 year ago

docker desktop for mac 4.17.0 (99724), the problem is still. In addition, 'mysql/mysql-server' has the same problem. At present, only grpc-fuse can be used.

aguckenber-chwy commented 1 year ago

Still seeing this issue

Ch4s3r commented 1 year ago

I also got some permission problems when running Kibana and Elastic with docker-compose:

FATAL  Error: EACCES: permission denied, open 'config/certs/ca/ca.crt'

Switching off containerd helped in my case. Also tested some scenarios and it showed that whenever I activated containerd it was going to fail with permission problems.

grpc fuse + containerd      = failure
virtiofs  + containerd      = failure

grpc fuse + no containerd   = works
virtiofs  + no containerd   = works

Maybe this also applies to others here?

anthonymich01 commented 10 months ago

Docker Desktop 4.23.0 (120376) on Intel MacOS Ventura 13.5.1

Use Virtualization framework making Segment fault Error 139 for React on Rails - shakapacker

VirtioFS + Virtualization framework       => Fail
gRPC     + Virtualization framework       => Fail
gRPC     + Uncheck Virtualization frmwrk  => Succeed

niccolomineo commented 10 months ago

Docker Desktop 4.23.0 (120376) on Intel MacOS Ventura 13.5.1

Use Virtualization framework making Segment fault Error 139 for React on Rails - shakapacker
VirtioFS + Virtualization framework       => Fail
gRPC     + Virtualization framework       => Fail
gRPC     + Uncheck Virtualization frmwrk  => Succeed

I just got the heads-up of the upgrade and now I am scared of going further.

rubysolo commented 10 months ago

I think I'm running into this issue as well -- Desktop 4.23.0 on MacOS Sonoma 14.0 (was also happening on Ventura) on M1. I run a container that bind-mounts my ~/.kube directory and uses the k8s Go SDK to switch contexts. This process creates a temporary lockfile to serialize updates to the config file.

When VirtioFS is enabled, it appears to be creating the lockfile with no/invalid permissions bits:

ls -l output from inside the container:

-????????? ? ?    ?        ?            ? config.lock

ls -l output from the host system:

---------- 1 [myuser] [mygroup] 0 Sep 14 21:13 config.lock

Then something (likely removal of the lockfile) fails with a permission denied error.

When the file sharing implementation is switched to gRPC FUSE, it works correctly.

kalevitan commented 9 months ago

Still seeing this permissions issue only when VirtioFS is enabled when trying to add node as a composer dependency to my Lando project. Node is added by pantheon-se/node-composer.

An error occurred while extracting (/app/vendor/node-v14.18.1-linux-arm64.tar.gz) to /app/vendor/node-v14.18.1-linux-arm64: tar: bin/npx: Cannot open: Permission denied
  tar: bin/npm: Cannot open: Permission denied
  tar: Exiting with failure status due to previous errors

llimllib commented 8 months ago

An easy way to reproduce is to try and run gitlab under virtio:

sudo docker run --detach \
  --hostname gitlab.example.com \
  --publish 443:443 --publish 80:80 --publish 22:22 \
  --name gitlab \
  --restart always \
  --volume $HOME/gitlab/config:/etc/gitlab \
  --volume $HOME/gitlab/logs:/var/log/gitlab \
  --volume $HOME/gitlab/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:latest

After the setup process completes, you'll find postgres logs in $HOME/gitlab/logs/postgresql/ with the error:

2023-10-25_15:06:54.26177 LOG:  starting PostgreSQL 13.11 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
2023-10-25_15:06:54.26436 LOG:  could not set permissions of file "/var/opt/gitlab/postgresql/.s.PGSQL.5432": Invalid argument
2023-10-25_15:06:54.26451 WARNING:  could not create Unix-domain socket in directory "/var/opt/gitlab/postgresql"
2023-10-25_15:06:54.26461 FATAL:  could not create any Unix-domain sockets

renkosteenbeek commented 8 months ago

Using OrbStack does solve these issues for me. It's much faster then Docker Desktop too. http://orbstack.dev

nulllpoint commented 8 months ago

Using OrbStack does solve these issues for me. It's much faster then Docker Desktop too. http://orbstack.dev

I just tried it. OrbStack is just a launcher, which has nothing to do with virtirfs......

mcabreb commented 5 months ago

Hello there, it has been more than a year with this bug. From release 4.14 to 4.27. gRPC FUSE is much slower than VirtioFS... Any news on the issue?

carlosfrodriguez commented 2 months ago

This is also reproducible with Docker Mailserver https://docker-mailserver.github.io/docker-mailserver/latest/

Apple Silicon Mac, Docker Desktop 4.29.0

bkline commented 2 weeks ago

@thaJeztah

I'm discussing with the team working on VirtioFS, and they're looking into it.

That was back in 2022. Are they still looking into it? Or have they decided this isn't a very important bug, and moved on to other things?

docker / for-mac