Open abentele opened 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.
Thanks for reporting; I just hit this issue myself; I'm discussing with the team working on VirtioFS, and they're looking into it.
Same here. For some reason all files inside my devcontainer are now marked as executable after a git pull
.
Same here, rolling back to 4.14.1 solves the problem
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.
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.
Switched back to "gRPC FUSE" for now. Seems like a good enough work around until a fix is in place.
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!
@abentele note that this executable bit issue is different for the issue you're facing. Investigation continues.
@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?
@oinopion thanks for feedback, it should land in our next release early next year
@fredericdalleau Thanks a lot for this Docker build!
4.16 preview works like a charm on my system, thank you for that. 👍
Closing this issue because a fix has been released in Docker Desktop 4.16. See the release notes for more details.
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
...
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
@pirog, can you share what command you used to get this result?
@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?
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)
@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.
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.
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)
@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.
@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:
osxsupport
branch which adds the ability to kick off build on OSX https://github.com/xEtherealx/batocera.linux/tree/osxsupportmake 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
@xEtherealx An error occurs : No rule to make target batocera-bcm2837_defconfig
. It also occurs on Linux host on master branch.
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
@thomas-schwieters could it relate to a long path? Could you try with a shorter volume path ?
- /Users/username/nodest:/data
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
@thomas-schwieters do you have a curl request that could be used after starting the container that triggers the error?
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
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.
@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?
@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?
@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?
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.
I just tried from my MacBook. Same issue, see screenshot.
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
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.
Still seeing this issue
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?
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
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.
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.
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
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
Using OrbStack does solve these issues for me. It's much faster then Docker Desktop too. http://orbstack.dev
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......
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?
This is also reproducible with Docker Mailserver https://docker-mailserver.github.io/docker-mailserver/latest/
Apple Silicon Mac, Docker Desktop 4.29.0
@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?
Summary / Steps to reproduce
I started a gitlab container with docker compose. This container has a volume:
what I did in the running container (note the commands access a sub-folder of the volume):
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.
Output of
/Applications/Docker.app/Contents/MacOS/com.docker.diagnose check
Steps to reproduce the behavior
See above.