New version of Docker won't start

[minus1kelvin]

I had updated to the new version 1.7.3 in the Docker and it will not load. The previous version was working fine besides a few times I had to restart it due to the "waiting for torrent selection" issue. Sadly, my Docker-fu is weak and I don't know how to get the previous version (I use rogerfar/rdtclient:latest but I can't figure out how to get the 1.7.2, sorry I'm a newbie).

[rogerfar]

What host are you running on?

[minus1kelvin]

Synology DSM6

[popophobia]

I think there is some error with the new build. The docker image is only about a third of the size of the previous version - 261.7 MB vs. 682.7 MB

Id	Tags	Size	Created
sha256:2b712cc832731f07fb65908915bdad...	rogerfar/rdtclient:latest	261.7 MB	2021-04-20 05:48:16
sha256:78d6871d61dec21ce59a7f70b4b68b...	rdtclient:1.7.2	682.7 MB	2021-04-15 06:19:47

There is a way to get around it, assuming you have an old version of 1.7.2 cached in your local computer. You can tag it as a specific local version and call docker-compose from there

docker tag 78d6871d61de rdtclient:1.7.2

78d6871d61de is the image ID of the previous version. Subsequently, you can start docker-compose but refer to image: rdtclient:1.7.2 instead of image: rogerfar/rdtclient

This should tie you over until the problem is fixed.

[rogerfar]

1.7.3 was build with the old dockerfile again, the 1.7.2 build was using the new linuxserver.io build, but that broke ARM support, so for now it's back to the working docker build again.

[popophobia]

I see. I'm running 1.7.2 on Synology DSM (x86) without any issue, but I couldn't start the previous version or 1.7.3.

Hopefully the ARM build will get sorted out with the linuxserver.io base image. Their suite is very versatile :)

Thanks for the cool app. I'm sticking with 1.7.2 for now since it works well on my system atm.

[ravensorb]

I pushed one under my account if you want to test it out: https://hub.docker.com/r/ravensorb/rdtclient

[rogerfar]

I pushed 1.7.4 docker too, after the pull request.

The only thing I didn't see what a specific 1.7.4 tag, not sure if that one will popup on the next release or is it not in the publish script?

[ravensorb]

Are you using the ps script I added? If so it has a new param for Version that will tag the image (if you don't specify it, it only tags it as latest, if you do it tags it with both)

[rogerfar]

I did use it yes, but didn't call it with a parameter no, maybe I should read the docs 😄

[Oorweeg]

fwiw, 1.7.4 wont start for me. The docker logs repeat the following every second:

: No such file or directory bash

All previous versions have started without issues.

Docker host is x86 running Fedora 33, Docker 20.10.6. Starting using docker-compose below (paths and IP addressing removed)

  rdtc:
    container_name: rdtc
    image: rogerfar/rdtclient
    restart: unless-stopped
    user: 1003:1003
    environment:
      TZ: Europe/London
      http_proxy: http://x.x.x.x:8888
      https_proxy: http://x.x.x.x:8888
    volumes:
      - /downloads:/data/downloads:
      - /db:/data/db:
    ports:
      - "6500:6500"
    network_mode: bridge

[Oorweeg]

Updated compose to adapt to the new linuxserver.io user workaround rather than the 'user: xxxx:xxxx' config as follows, still have the same error as reported above so I don't this is related to the startup problem?

  rdtc:
    container_name: rdtc
    image: rogerfar/rdtclient
    restart: unless-stopped
    environment:
      TZ: Europe/London
      http_proxy: http://x.x.x.x:8888
      https_proxy: http://x.x.x.x:8888
      PUID: 1003
      PGID: 1003
    volumes:
      - /downloads:/data/downloads:
      - /db:/data/db:
    ports:
      - "6500:6500"
    network_mode: bridge

Off topic: Separate note that it might be worth updating the readme or release notes to advise that the config format for permissions settings/container user has changed for docker users as other people might be using the container with the 'user' config that doesn't seem compatible with the new changes? I believe this is specifically because these were created for older versions of docker that don't support running the container as specific users? Is that the correct approach for something that did work with the modern way of setting this up? (I'm not bothered wither way but seemed worth understanding what these workarounds are for and that there was already a simple way to get the container running with the permissions needed?)

[ravensorb]

@timcoop3r - Can you try the temp one that I published at ravensorb/rdtclient:latest (everything else can stay the same -- just change the image name)

[Oorweeg]

@timcoop3r - Can you try the temp one that I published at ravensorb/rdtclient:latest (everything else can stay the same -- just change the image name)

Yep that's starting normally

[ravensorb]

Ok, thanks. Interesting thing is -- I just do a git clone off the main repo, built locally, and ran the image and it also worked without issue. Granted, I am doing the build on linux -- wonder if there is an odd "line ending" issue when building on windows?

Edit: Ok, so I think that is actually the issue. I ran the main image that is having the issue, shelled into it, installed dos2unix and convert the "run" file that starts the service and all of a sudden it started up.

@rogerfar do you want me to update the docker build file to do this automatically?

[rogerfar]

Yeah I think that's a good idea.

[phirestalker]

I think there is some error with the new build. The docker image is only about a third of the size of the previous version - 261.7 MB vs. 682.7 MB

Id Tags Size Created sha256:2b712cc832731f07fb65908915bdad... rogerfar/rdtclient:latest 261.7 MB 2021-04-20 05:48:16 sha256:78d6871d61dec21ce59a7f70b4b68b... rdtclient:1.7.2 682.7 MB 2021-04-15 06:19:47 There is a way to get around it, assuming you have an old version of 1.7.2 cached in your local computer. You can tag it as a specific local version and call docker-compose from there

docker tag 78d6871d61de rdtclient:1.7.2

78d6871d61de is the image ID of the previous version. Subsequently, you can start docker-compose but refer to image: rdtclient:1.7.2 instead of image: rogerfar/rdtclient

This should tie you over until the problem is fixed.

When I do that it says the image has been removed and something about losing data in the volumes. Is there another way to roll back until this is fixed?

[ravensorb]

The size difference is due to using a different base image -- we moved from the microsoft dot net image to a linuxserver.io base image which is substantially smaller. The fix seems to be working in my test env, so I'll submit a PR tomorrow with the updated dockerfile and that should get everything working again.

[Gotcha007]

re-created my docker container and pulled the latest image but still having the same issue exec: fatal: unable to exec bash: No such file or directory

[ravensorb]

@rogerfar just pushed a pr that now has dos2unix process the scripts files after they are copied into the container

@Gotcha007 if you need something now, you can pull this image down

[rogerfar]

I have published the new image with the patches, so if you pull now it should be all good.

[phirestalker]

I get this with the new image.

Starting rtdclient
./run: line 13: /usr/bin/s6-setuidgid: Permission denied
./run: line 13: exec: /usr/bin/s6-setuidgid: cannot execute: Permission denied

My docker-compose.yml is as follows:

version: '3.3'
services:
    rdtclient:
        container_name: rdtclient
        user: 1000:1000
        environment:
            - PUID=1000
            - PGID=1000
        volumes:
            - /mnt/media/downloads:/data/downloads
            - db:/data/db
        image: rogerfar/rdtclient:latest
        restart: always
        logging:
            driver: json-file
            options:
                max-size: 10m
        ports:
            - '6500:6500'
volumes:
    db:

[rogerfar]

Your volumes look a bit odd, you sure - db:/data/db is correct?

[phirestalker]

It was working before. I am using a named volume there since I didn't care about where it was stored.

[rogerfar]

Doublecheck of the permissions of the db and /mnt/media/downloads are writable to user 1000.

[phirestalker]

Yep, both are owned by user and group 1000.

[rogerfar]

@ravensorb any idea how to troubleshoot this?

@phirestalker what host are you running on?

[phirestalker]

I am running on Ubuntu 20.04 on a snap installed docker.

Docker version 19.03.13, build cd8016b6bc

EDIT: I opened another issue and the fix was using user: 1000:1000, but another issue mentions a move to the environment variables PUID and GUID. I left both in to cover all of my bases. I wonder if having both is causing some kind of conflict? If so, which one should I use with the new linuxserver.io based images?

[phirestalker]

Eureeka! I commented out the user: 1000:1000 line and it works! Thanks for all the help.

[Oorweeg]

EDIT: I opened another issue and the fix was using user: 1000:1000, but another issue mentions a move to the environment variables PUID and GUID. I left both in to cover all of my bases. I wonder if having both is causing some kind of conflict? If so, which one should I use with the new linuxserver.io based images?

The linuxserver.io images are not compatible with the modern docker 'user: xxxx:xxxx' setting so you do need to remove this option as you have discovered.

[rogerfar]

Hmm that shouldn't, did you do a hard refresh? Ctrl+F5?

[Oorweeg]

Hmm that shouldn't, did you do a hard refresh? Ctrl+F5?

Damn it, I deleted that comment straight away! :P Was looking in the wrong tab :)

[ravensorb]

@phirestalker setting the ENV variables for PGID and PUID allow you to override the default values of 1000 (so if you want to map the user/group in the container to one on the host, you can set them via the ENV variables in the compose or run command. If you set them to 1000 it is effectively the same thing as not setting them at all so no conflict to worry about.

[ravensorb]

@timcoop3r can you point me to the documentation on dockers website around the "user: xxxx:xxxx"? I can dig into it and see whats going on.

[Oorweeg]

@timcoop3r can you point me to the documentation on dockers website around the "user: xxxx:xxxx"? I can dig into it and see whats going on.

I'm just quoting the official stance from linuxserver.io here: https://docs.linuxserver.io/general/understanding-puid-and-pgid

"We are aware that recent versions of the Docker engine have introduced the --user flag. Our images are not yet compatible with this, so we recommend continuing usage of PUID and PGID."

[ravensorb]

@timcoop3r thanks for that. I was just curious as I cannot find any reference to the "user" tag in the docker documentation or the compose spec reference. Maybe its experimental?

[Oorweeg]

@timcoop3r thanks for that. I was just curious as I cannot find any reference to the "user" tag in the docker documentation or the compose spec reference. Maybe its experimental?

I think it's documented here: https://docs.docker.com/engine/reference/run/#user

[ravensorb]

Ok, it looks like this might be an issue with the "user: xxxx:xxxx" -- setting that causes the parts of the filesystem inside the running container to be inaccessible (ex: cannot access /root path). If you remove the "user: " line from your compose it should work. I am running a few tests now

[ravensorb]

@timcoop3r thanks for that. I was just curious as I cannot find any reference to the "user" tag in the docker documentation or the compose spec reference. Maybe its experimental?

I think it's documented here: https://docs.docker.com/engine/reference/run/#user

Looks like a new feature -- nice, that should make things easier in the long run For now, it is breaking the image :)

[Oorweeg]

@timcoop3r thanks for that. I was just curious as I cannot find any reference to the "user" tag in the docker documentation or the compose spec reference. Maybe its experimental?

I think it's documented here: https://docs.docker.com/engine/reference/run/#user

Looks like a new feature -- nice, that should make things easier in the long run For now, it is breaking the image :)

Depends what you consider 'new' :P

People started asking for support for this option to be added to docker-compose back in 2015 ;)

But yeah, lots of us were using this to fix permissions, so it would probably be handy to add a note about the change in the release notes as its clearly broken startup for a few people that have pulled the latest updates. Also worth documenting in the main readme on the 'supported' way to set this in the container going forwards.

[ravensorb]

@rogerfar is it possible the new build used a slightly old version of the repo? It looks like the latest image has a reference to a folder that I had renamed (fixed a spelling error). In the latest image that is on docker hub there is a path for /etc/services.d/rtdclient -- I had fixed the name so that it was should be /etc/services.d/rdtclient Right now the fix for the line endings is trying to fix a file that doesn't exist since the new path isn't found in the image.

[rogerfar]

I did rebuild the whole image though, shouldn't it have pulled the renamed file in?

[rogerfar]

Yeah, why not just change the

# add local files
COPY root/ /

to something like

# add local files
COPY --from=node-build-env root/ /

It does a git checkout, so the files should be there, correct?

[ravensorb]

Ok, never mind issue was on my end (sheepish look) -- I had an older image that I forgot to clear out. So just confirmed that using the latest image with OUT the "user" in the compose file works.

Also -- I was thinking, maybe I change the dockerfile to grab the files from git rather than using a local docker add? This might actually fix the line ended issue and make sure everything always matches?