Latest image won't start

[TheGITofTeo997]

Hello, I have been trying to update from my beta16 to the latest 1.0.2 docker image. However it keeps staying on starting and then it does not work and goes to unhealthy, also tried on other machines but no luck. Any ideas?

[nillebor]

I just tested it for another user on the synology diskstation. The :latest version 1.0.2 works here without any problems.

See here:

@mxschmitt, very good work, many thanks. I found a small bug: Image Info, link on dockerhub does not work (Fault 404).

[TheGITofTeo997]

So, turns out i solved it but requires some thinkering. This is a dirty way we've been discussing on the Discord support. I will attach the screenshots where I documented everything while explaining so everyone can see the solution.

So apparently, since this version, if you run as root it simply WON'T work. You need to create and chown the folders to the correct users as documented in docker hub. If you then use docker run withOUT:

-e UID=$(id -u sinusbot) \
-e GID=$(id -g sinusbot) \

it will simply NOT work. If you put those and use docker run you are well finished. Problems arise when you use docker compose. You can't pass host variables directly and you have to use them in the inline invocation. So i did UID=$(id -u sinusbot) GID=$(id -g sinusbot) docker compose up -d but turns out you can't do it either because UID and GID are reserved by bash so i ended up with SINUID=$(id -u sinusbot) SINGID=$(id -g sinusbot) docker compose up -d in a bash script which is a very dirty way to invoke up my stack in my opinion. So if i am not doing anything wrong this should be worked on in a better way.

[nillebor]

Yes, I also specified the UID and GID in the container. If these are missing, you can also see this in the log.

If you had specified the log here, the solution would have come faster ;)

The problem is solved, please close the topic.

[TheGITofTeo997]

Yes, I also specified the UID and GID in the container. If these are missing, you can also see this in the log.

If you had specified the log here, the solution would have come faster ;)

Sure, but i think it'worth nothing that for the previous 5+ years i've been simply running Sinusbot with

docker run -d -p 8087:8087 \
           -v /opt/sinusbot/scripts:/opt/sinusbot/scripts \
           -v /opt/sinusbot/data:/opt/sinusbot/data \
           --name sinusbot \
           sinusbot/docker

thing that i expected working also with this version (this was the default command). Even though discouraged the bot has always been running as root without issues. Now, if this change has become mandatory from this version maybe it should be worth specifying it

EDIT: Furthermore, I don't think running docker compose stack with a script in front of it to specify variables is the neatest way to do this. I might be missing something so if someone knows a better way to specify those two environments please comment here

[nillebor]

Take a look at your old log. There is a reference to rights there.

I had only tested it for another user and had no problems. The same error occurred without specifying the UID and GID. You could see that very well in the log. A log is not there for nothing.

It also depends on the device.

But it doesn't matter; it works for you now. Be happy :)