-
-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] "chmod: changing permissions of '/XXX': Bad address" error message #514
Comments
Same issue with streamlined compose swag:
container_name: swag
image: ghcr.io/linuxserver/swag
ports:
- 81:81
volumes:
- ${APPDATA_DIR}/Swag:/config
environment:
- PUID=${PUID}
- PGID=${PGID}
- TZ=${TIMEZONE}
- URL=${DOMAIN}
- SUBDOMAINS=wildcard
networks:
container_network:
restart: unless-stopped additional details in discord thread: |
I can't reproduce. Are you on qnap as well? |
Yes, with latest firmware and container station versions. |
I see the same chmod errors with a lot of my containers including swag. It seems to have messed up permission on nextcloud container. Also qnap Docker version 27.1.2-qnap2, build d46fd47. |
Can you provice the output of Also what filesystem is your QNAP storage using? ext4? btrfs? etc. |
Docker was recently upgraded, but system hasn't been updated in a while. I have not seen this errors before, though I don't look at the logs unless I expect problems with an docker container upgrade for instance. Filesystem is zfs
|
Sorry for the delay, was away for few days. Here the outputs : uname -a : and docker info :
|
Hello, same thing for me in Storage Driver: overlay2 [~] # docker info Server: |
Hello, |
My guess is it'll affect any image that performs a chmod on init. Can you post the relevant logs from the |
here you go : `[migrations] started
Brought to you by linuxserver.io To support the app dev(s) visit: To support LSIO projects visit: ─────────────────────────────────────── User UID: 1000 using keys found in /config/keys |
This is definitely an issue that affects chmod in docker on qnap specifically. Something to do with the docker install there or the kernel, or an incompatibility between the two. I don't believe there is anything we can do. It likely needs to be updated/fixed by qnap. Iirc we had similar issues reported with chmod some time ago (maybe more than a couple of years ago) and the issue was later resolved by updates. In this case the container still goes through the rest of the init and the services seem to start. |
It's almost impossible to usefully troubleshoot because 99% of search results for "Bad Address" are DNS related; I've even gone through the coreutils source and it doesn't seem to be a native error message, which suggests it's being returned by the OS/kernel. I did find this: alpinelinux/docker-alpine#342 but it seems to be specific to 32bit arm. The gitlab tracking issue is https://gitlab.alpinelinux.org/alpine/aports/-/issues/15167 |
Thank you. I will open a case at qnap |
Could you do the following as well.
Then run (then |
May be worth testing if chmod works in Ubuntu as well |
here the result : `docker run -it --rm alpine:3.20 sh / # ulimit -a |
So if you do
Do you get the same error? If so can you exit then do
Do you get the same error? |
No message appears : same result after a container restart |
Same here, no message /# docker run -it --rm alpine:3.20 sh And still the same situation after a container restart (ie speedtest) |
Interesting, so it's not just any chmod operation that causes it. Can you try running
Then do a Edit: The image is just our Alpine base image that then installs logrotate and does the same chmod as swag etc. and then also performs some other chmods to see which (if any) trigger the errors. |
Sure. Here the result : /# docker run -d --rm --name=chmod thespad/playground:chmod | | | | | | | | Based on images from linuxserver.io To support LSIO projects visit: ─────────────────────────────────────── User UID: 911 |
OK, so across the board. And can you try with |
Here the outcome : /# docker kill chmod | | | | | | | | Based on images from linuxserver.io To support LSIO projects visit: ─────────────────────────────────────── User UID: 911 |
OK so no difference between busybox chmod and gnu chmod. Final test for now, I promise.
|
No issue at all, my pleasure to help as I can Here the result : / # docker kill chmod |
OK, turns out I lied because the tests we did with the basic alpine image weren't identical so can you do the same test again but with My guess is it's only affecting the recursive part of the chmod as there's no error for the parent folder in any of the tests and the one you did earlier with |
Well, not fully sure about the exact command you expect me to run. Tying the following one didn't go through, but this might not be correct /# docker kill chmod |
Sorry, I mean literally just |
Like that ? /# docker run -d --rm --name=chmod alpine:3.20 But the next steps failled (sorry, my knowledge level is still pretty low) [/share/CACHEDEV1_DATA/Container] # apk add linux-pam No output |
Sorry, should have been explicit.
|
unfortunately, it does not go through at the second command line : /# docker run -d --rm --name=chmod alpine:3.20 |
Sorry, being stupid, the basic container doesn't have a supervisor so just stops if it doesn't have anything to do
|
Here the outcome /# docker run -it --rm alpine:3.20 Restarting the Speedtest container still show the chmod error during the start sequence |
Well that's annoying, it doesn't happen in the base alpine image but does in our base so it must be something we're changing or adding. @j0nnymoe going to need you to fire up your QNAP here. |
Happy to do any further test when ever required, just let me know. I can only add that it worked well up to few months ago (guess up to 3-4 months ago). Really appreciate your help here ! |
Is there an existing issue for this?
Current Behavior
During swag container start, several chmod error message appear in the log. I've checked all related file and folder permission and find them all correct for the user.
However, SWAG proxy seems to be working fine and proxied container are reachable as expected
Not really sure when the issue started as I saw it few days ago only, but can confirm the issue was not there few months ago, with the same config.
Expected Behavior
start without error message.
Steps To Reproduce
Happens at every start.
Environment
CPU architecture
x86-64
Docker creation
Container logs
The text was updated successfully, but these errors were encountered: