mirror of
https://github.com/yusing/godoxy.git
synced 2026-01-14 07:33:36 +01:00
exec /app/run: operation not permitted #91
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @zachkont on GitHub (Jul 9, 2025).
I recently replaced the drive where godoxy was happily running as a compose file and since then I can't start it successfully. Instead, I keep getting a
error in the
godoxy:v0.15.3container logs and ain the
godoxy-frontend:v0.15.3container logs. Thegodoxy-socketcontainer logs indicate that it's running fine I thinkI am fairly certain it's a permissions issue but I cannot figure out what exactly. I have tried moving the mounted volume from the
/data/compose/godoxydirectory where it was running before the drive change to a directory in my home, I have tried different ownership schemes (root:root,root:docker,user:docker) while always making sure thatGODOXY_UIDandGODOXY_GIDhave the correct values set but I keep getting the same message. I also tried deleting everything inside the mounted directories and letting the container create new entries but it only created the sub-dirs and nothing else and the error kept showing up in the logs. One note is that the subdirs were created withroot:rootownership even though the env vars pointed touser:docker. I should also mention I'm running them through a portainer-gitops setup.@yusing commented on GitHub (Jul 10, 2025):
Does it happen on any other containers?
@zachkont commented on GitHub (Jul 10, 2025):
no, all the others were moved without issue
@yusing commented on GitHub (Jul 11, 2025):
Have you tried with UID 0 and GID 0?
@zachkont commented on GitHub (Jul 11, 2025):
Yes, the combinations I've tried are 0:0 and 1000:1001 (my user and the docker group which matches the mounted volume permissions)
@yusing commented on GitHub (Jul 11, 2025):
I guess you could try removing
cap_dropandsecurity_optsfrom docker compose file and try again.Also may I know your docker engine version?
@zachkont commented on GitHub (Jul 27, 2025):
Sorry for taking so long to reply
and after removing
cap_dropandsecurity_opsit now starts but has trouble creating any files it needs I think. First I got an error about being unable to open/config/config.ymlwhich I copied over into the volume mount from my backup and now I getcert.crtis a file in my backup but if I copy it over I getand if I create an empty directory I get
@yusing commented on GitHub (Jul 27, 2025):
Fixed, please pull again
@zachkont commented on GitHub (Jul 27, 2025):
Everything works now, thanks! I'm not familiar with
cap_dropandsecurity_opt, is it ok to keep it running without them? why did changing them fix it? It looks like they were being used to reduce the permissions of the container so I guess I'm just trusting the image more with them gone?@yusing commented on GitHub (Aug 3, 2025):
Idk what changes you have made to the system other than replacing the drive so cannot tell why it does not work with those security features. Yup it is still safe without them.