Trying To Change Custom App Entrypoint Fails

Apps and Virtualization
, ,
1

I’ve got a custom app (gotosocial) docker container that is working fine with the default entrypoint specified in it’s config file. But I want to temporarily run the container with an overriden entrypoint.

No matter what I specify, though, it fails. /var/log/app_lifecycle.log shows a series of “no such file or directory” errors, even when I know the files I’m trying to call are definitely there, as I can access them if I attach to the container.

Is there some special formatting needed for adding the entrypoint in the Container Configuration part of the webui?

What I want to run is:
/gotosocial/gotosocial admin media prune orphaned

I’ve tried just putting that in the web UI, but also
“/gotosocial/gotosocial”, “admin”, “media”, “prune”, “orphaned”

Neither work:

[2026/09/03 16:26:54] (ERROR) app_lifecycle.compose_action():58 - Failed 'up' action for 'gotosocial-docker' app:  gotosocial-docker Pulling \n gotosocial-docker Pulled \n Network ix-gotosocial-docker_default  Creating\n Network ix-gotosocial-docker_default  Created\n Container ix-gotosocial-docker-gotosocial-docker-1  Creating\n Container ix-gotosocial-docker-gotosocial-docker-1  Created\n Container ix-gotosocial-docker-gotosocial-docker-1  Starting\nError response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "/gotosocial/gotosocial admin media prune orphaned": stat /gotosocial/gotosocial admin media prune orphaned: no such file or directory: unknown\n
[2026/09/03 16:42:31] (ERROR) app_lifecycle.compose_action():58 - Failed 'up' action for 'gotosocial-docker' app:  gotosocial-docker Pulling \n gotosocial-docker Pulled \n Network ix-gotosocial-docker_default  Creating\n Network ix-gotosocial-docker_default  Created\n Container ix-gotosocial-docker-gotosocial-docker-1  Creating\n Container ix-gotosocial-docker-gotosocial-docker-1  Created\n Container ix-gotosocial-docker-gotosocial-docker-1  Starting\nError response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "\"/gotosocial/gotosocial\", \"admin\", \"media\", \"prune\", \"orphaned\"": stat "/gotosocial/gotosocial", "admin", "media", "prune", "orphaned": no such file or directory: unknown\n
2

yeah in my experience the apps ui entrypoint field is weird about this

looking at your log it kinda looks like the whole string got treated as one binary name, spaces and all. so docker tries to exec /gotosocial/gotosocial admin media prune orphaned as a single file and then shrugs

might work better if you leave entrypoint as just /gotosocial/gotosocial and put admin media prune orphaned in the command / args field instead (or however the custom app form splits those). or run it once with docker exec against the already running container and leave the entrypoint alone for the service itself

probably worth a quick try before fighting the yaml more

3

Yeah, I think that’s the problem: the web UI doesn’t offer separate fields for the command and arguments, and it’s intuitive (although it’s laid out in documentation) that you can use the CMD functionality to add arguments to the ENTRYPOINT in addition to it’s primary purpose.

This is confusing docker functionality cascaded to the TruesNAS Scale web UI :man_shrugging:

Anyways, I tried splitting the command and arguments across ENTRYPOINT and CMD and it doesn’t throw an error now, but does restart the container a few times, so quickly that I’m unable to see the logs through the web UI. I think I’ll need to get this done on the cmdline somehow.

4

in my experience that “no such file or directory” on a custom entrypoint is almost always the path/form, not the app itself. SCALE’s custom app UI can be picky about entrypoint vs command, and if you pass a shell-style string instead of the real binary path inside the image it blows up like that. i’d docker inspect the working default image and copy whatever Entrypoint/Cmd it actually uses, then only override the piece you need. might also be that the binary isn’t on PATH in that image so you need the full path. shrug, worth a look at the lifecycle log right above the fail line too