exec /app/run: operation not permitted #91

Closed
opened 2025-12-29 09:22:55 +01:00 by adam · 9 comments
Owner

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

exec /app/run: operation not permitted

error in the godoxy:v0.15.3 container logs and a

exec /nodejs/bin/node: operation not permitted

in the godoxy-frontend:v0.15.3 container logs. The godoxy-socket container logs indicate that it's running fine I think

2025/07/09 21:49:50 Docker socket listening on: 0.0.0.0:2375

I 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/godoxy directory 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 that GODOXY_UID and GODOXY_GID have 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 with root:root ownership even though the env vars pointed to user:docker. I should also mention I'm running them through a portainer-gitops setup.

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 ``` exec /app/run: operation not permitted ``` error in the `godoxy:v0.15.3` container logs and a ``` exec /nodejs/bin/node: operation not permitted ``` in the `godoxy-frontend:v0.15.3` container logs. The `godoxy-socket` container logs indicate that it's running fine I think ``` 2025/07/09 21:49:50 Docker socket listening on: 0.0.0.0:2375 ``` I 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/godoxy` directory 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 that `GODOXY_UID` and `GODOXY_GID` have 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 with `root:root` ownership even though the env vars pointed to `user:docker`. I should also mention I'm running them through a portainer-gitops setup.
adam closed this issue 2025-12-29 09:22:55 +01:00
Author
Owner

@yusing commented on GitHub (Jul 10, 2025):

Does it happen on any other containers?

@yusing commented on GitHub (Jul 10, 2025): Does it happen on any other containers?
Author
Owner

@zachkont commented on GitHub (Jul 10, 2025):

no, all the others were moved without issue

@zachkont commented on GitHub (Jul 10, 2025): no, all the others were moved without issue
Author
Owner

@yusing commented on GitHub (Jul 11, 2025):

Have you tried with UID 0 and GID 0?

@yusing commented on GitHub (Jul 11, 2025): Have you tried with UID 0 and GID 0?
Author
Owner

@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)

@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)
Author
Owner

@yusing commented on GitHub (Jul 11, 2025):

I guess you could try removing cap_drop and security_opts from docker compose file and try again.

Also may I know your docker engine version?

@yusing commented on GitHub (Jul 11, 2025): I guess you could try removing `cap_drop` and `security_opts` from docker compose file and try again. Also may I know your docker engine version?
Author
Owner

@zachkont commented on GitHub (Jul 27, 2025):

Sorry for taking so long to reply

❯ docker -v
Docker version 28.1.1+1, build 068a01e

and after removing cap_drop and security_ops it now starts but has trouble creating any files it needs I think. First I got an error about being unable to open /config/config.yml which I copied over into the volume mount from my backup and now I get

07-27 07:20 INF GoDoxy version v0.16.1

07-27 07:20 INF loaded route providers

                  • docker@local 9 routes

                

07-27 07:20 FTL autocert setup error

                  • failed to update last failure: open certs/cert.crt/.last_failure: no such file or directory

cert.crt is a file in my backup but if I copy it over I get

07-27 07:26 FTL autocert setup error

                  • open certs/cert.crt/.last_failure: not a directory

and if I create an empty directory I get


07-27 07:27 FTL autocert setup error

                  • load SSL certificate: read certs/cert.crt: is a directory
@zachkont commented on GitHub (Jul 27, 2025): Sorry for taking so long to reply ``` ❯ docker -v Docker version 28.1.1+1, build 068a01e ``` and after removing `cap_drop` and `security_ops` it now starts but has trouble creating any files it needs I think. First I got an error about being unable to open `/config/config.yml` which I copied over into the volume mount from my backup and now I get ``` 07-27 07:20 INF GoDoxy version v0.16.1 07-27 07:20 INF loaded route providers • docker@local 9 routes 07-27 07:20 FTL autocert setup error • failed to update last failure: open certs/cert.crt/.last_failure: no such file or directory ``` `cert.crt` is a file in my backup but if I copy it over I get ``` 07-27 07:26 FTL autocert setup error • open certs/cert.crt/.last_failure: not a directory ``` and if I create an empty directory I get ``` 07-27 07:27 FTL autocert setup error • load SSL certificate: read certs/cert.crt: is a directory ```
Author
Owner

@yusing commented on GitHub (Jul 27, 2025):

Fixed, please pull again

@yusing commented on GitHub (Jul 27, 2025): Fixed, please pull again
Author
Owner

@zachkont commented on GitHub (Jul 27, 2025):

Everything works now, thanks! I'm not familiar with cap_drop and security_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?

@zachkont commented on GitHub (Jul 27, 2025): Everything works now, thanks! I'm not familiar with `cap_drop` and `security_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?
Author
Owner

@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.

@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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/godoxy#91