[Docker] Channels can't start. Have to chown directory after container restart

Anyone have any ideas on why the perms get messed up following reboots and I have to chown the directory each time to allow the DVR server to boot?

Which directory?

It was the timstephens24 image. I switch to the fancy but image and it hasn’t happened again yet.

But the /data directory was causing the issues on that image

cc @timstephens24

My image is made to be run by a non-root user and should be mapped to a non-root user. Some people were having issues so I modified it on start to ensure the files were the correct user. Are you setting the uid and gid when you start the container?

Yea I'm sure. I've been running it at my 1000 user just like all my other containers for that last year or two. And it worked perfectly fine until recently it would start borking on a restart of the container and I would have to chown that directory then it would work perfectly fine.

Can you show me how you’re running the container?

image

Maybe the security option is causing the issue with the changes you made?

Thanks! I’ll spin up an Ubuntu VM tomorrow hopefully and test it out and see if I can figure something out.

Ok cool!

This one was very weird, so first off thanks again for bringing it up, I ended up learning a lot!

I think I have it fixed now, so if you wouldn't mind testing it out for me that would be fantastic! To do that please just change your compose image line to add in the beta tag:
image: timstephens24/channels-dvr:beta
I won't update the main image until I can test this out on my Unraid server to make sure there's no issues with those vs Ubuntu and have that running for a bit.

I'm not sure specifically what the issue was, but I could recreate your issue only on the first pull of the image after a clean boot. I couldn't recreate it again even using new images until after I rebooted, so I was really stumped for a while. It seemed to only set the uid to 99 on the initial start, but the 'abc' user in the container was set correctly to 1000. It was very weird since a uid of 99 is never specified anywhere and doesn't exist in the image, only the user abc and that's mapped with the container environment variables.

Ultimately if I rebased back to a Ubuntu 20.04 LTS baseimage everything would run fine. I think it was an issue specific to the newer Ubuntu 22.04 LTS that didn't happen in 20.04 LTS along with an update that occurred for s6-overlay. I completely redid all of the startup for the container based on s6v3 and it finally works properly (at least from what I can tell so far).

Yea I'll check it out. Thanks for looking into it

Pulling the image same issue.

After chown, boots up and spam logging stops

Who was the owner originally? UID 1000 user or someone else?

1000

Seems like it only affected it after that very first run. I even remove the image and went back to fancy bit and came back again and it was still fine.

So I can leave it running and for a few days and see if anything changes

image

This is what the log shows when it boots correctly

And 1000 is showing in the user list so not sure

image

Ok thanks, I'll mess around with permissions prior to loading a bit tonight and see if I can recreate that and come up with a way around it.

1 Like