#Migration from jellyseerr: is --user still supported? is --init needed?

40 messages · Page 1 of 1 (latest)

quiet ermine
#

Hi, I just migrated from jellyseerr to seerr (docker)

I use a dedicated, limited user for my containers, and I'd rather continue to use seerr with it. Can I continue using the user: instruction then? That user isn't 1000:1000

The migration guide mentions that init: true should be added. But seerr seems to work fine without. Is it some specific usecase that requires that?

I'm asking because I initially tried without the init: true instruction and by keeping my user: instruction I had for jellyseerr, and seerr seems to work fine for now, no error or warning in the logs.

For reference, here's my compose:

services:
  seerr:
    image: ghcr.io/seerr-team/seerr:latest
    container_name: seerr
    user: 1030:65536
    environment:
      - TZ=Europe/Brussels
    volumes:
      - /docker/appdata/seerr:/app/config
    restart: unless-stopped
    healthcheck:
      test: wget --no-verbose --tries=1 --spider http://localhost:5055/api/v1/status || exit 1
      start_period: 20s
      timeout: 3s
      interval: 15s
      retries: 3
bright sphinx
quiet ermine
#

Thanks for the link to the init discussion, will read up on that. To be clear that point was just me being curious, I'm fine with adding init: true to the compose

Regarding the user thing, I get that, but still it seems to work fine. On the host everything under /docker/appdata/seerr is owned by 1030:65536. In the container in looks like this: https://privatebin.net/?4546189f6a9f5675#2yc2RpiXA7c3cbFyZh3Z9Z9AkAv33NS9GZfjiXs5rVk3

the npm/node processes are running as 1030 here but it seems that they can still use the files & folder under /app owned by user 1000/node

PrivateBin
Encrypted note on PrivateBin

Visit this link to see the note. Giving the URL to anyone allows them to access the note, too.

bright sphinx
#

because they have read only access I suppose

#

and do not need other things

#

when I say it's not supported it's more we never tested it (because it does not make really sense to choose an user in a docker container) and it could break on an other release

quiet ermine
#

alright cool, thanks. I'll think about it, and keep in mind that if anything breaks it's on me lol

Why do you say it doesn't make sense to set a user for a container? I tend to do that to isolate things a bit better, so I know processes running in my containers can only ever see/read/right/exec what the limited user can

bright sphinx
quiet ermine
#

yeah that's true I suppose. I've been thinking of migrating my stuff to podman for better handling of stuff like this, my dedicated docker-limited user was already a bit of a band-aid to try and get something podman does better

#

I guess you already handle what I'm trying to handle by setting the USER in the dockerfile anyways

bright sphinx
#

I use kubernetes so I handle it but in an other way 😄

quiet ermine
# bright sphinx It make sense to use a non root user but do not make sense to choose one 🙂 You ...

I'd still push back a bit on this, because my 1000:1000 user is a sudoer, my docker-limited user isn't (and has some other limitations like no login shell). For normal operations I agree it doesn't matter, but if this container ever gets a container escape vulnerability it potentially could. I know it's paranoid and unlikely, I'm just saying I think there's technically still a reason to support setting the user to something else than 1000

bright sphinx
#

If you use userns-remap as I linked you will have no issue

#

and no we can't, because how do you handle remapping user at runtime ? with something like PUID/PGID like s6-overlay used in linuxserver image ? The container is run as root and change user at runtime that is not the good way to do it nowadays

quiet ermine
#

the reason I have this whole setup with a dedicated user is mostly because it works great with images using an s6 overlay like lsio yeah. I agree that userns-remap is the better tool for what I'm trying to do (and that what you do in the dockerfile makes more sense than a s6 layer for that matter), it's just not very convenient for me to migrate to that now as all my containers would be affected (unless there's a way to set it per-container, but I don't think you can).
But it's fine, I get it and I agree, I'm not gonna ask that you change your design to an inferior one with an s6-overlay to handle that. 🙂

quiet ermine
bright sphinx
#

in kubernetes you can change the user because we have primitive for that let me link you that

#

the main issue with user change is to handle file permission

#

which kubernetes solve

#

you can say, hey this fs should be 1000, if it isn't just chown it

quiet ermine
#

huh yeah that's neat. I'll add that to the pile of things pushing me to migrate my arr stack to k8s lol

bright sphinx
#

ahahah, docker is cool for dev but when you know how it works and how to use it you just don't go back from kubernetes to docker. But the main point is to know and understand how it works because it's really more complicated

quiet ermine
#

no for sure, I work with kubernetes and love it lol, I've been tempted to move my homelab to it but since a lot of apps are kinda designed as monolithic services I've been on the fence (like, I'm not sure any of my containers would handle being replicated, so it feels a bit weird setting up a cluster of monolithic, 1-replicas deployments lol).

Podman though is appealing for the imo way better handling of user namespaces

#

anyways, as far as my support question is concerned, it's resolved. Thanks!

bright sphinx
#

ahhh yeah most apps do not works with multiple replicas so you just configure them to 1

#

so you don't gain HA setup but if a node fail it can move to an other one for this type of apps

quiet ermine
#

but thanks I'm definitely bookmarking that

bright sphinx
quiet ermine
bright sphinx
#

otherwise I would invest time in komodo or something like that but I will still at the end been constraint by docker vs kubernetes power 😄

bright sphinx
quiet ermine
#

I'm trying with a "drop-in Dockerfile" kind of, it looks like this:
Dockerfile:

FROM ghcr.io/seerr-team/seerr:latest AS base

FROM node:22.22.0-alpine3.22@sha256:0c49915657c1c77c64c8af4d91d2f13fe96853bbd957993ed00dd592cbecc284

WORKDIR /app
COPY --from=base --chown=1030:65536 /app /app

USER 1030:65536
CMD ["npm", "start"]

compose.yml:

services:
  seerr:
    build:
      context: .
      pull: true
    image: seerr-custom:latest
    container_name: seerr
    user: "1030:65536"
    init: true
    environment:
      - TZ=Europe/Brussels
    volumes:
      - /docker/appdata/seerr:/app/config
    restart: unless-stopped
    healthcheck:
      test: wget --no-verbose --tries=1 --spider http://localhost:5055/api/v1/status || exit 1
      start_period: 20s
      timeout: 3s
      interval: 15s
      retries: 3

It seems to work nicely for my usecase. It does add some maintenance on the dockerfile (namely updating the base node image when you guys do as well), but I can live with that. (I first tried with a very basic dockerfile based on the seerr:latest image, that just used a RUN chown 1030:65536 -R /app, but that breaks docker's CoW so it takes super long and makes an image that's twice as large)

Just thought I'd mention this here so it's there in case someone finds themselves in a similar situation. I fully realize that this is still a band-aid, but it's one that works well enough for me

bright sphinx
#

people often use hotio or linuxserver image for that use case I guess but still thanks for sharing 🙂

quiet ermine
#

lmao shit I didn't realize I could just use those images 💀 lol

bright sphinx
#

xD

quiet ermine
#

istg tunnel vision on that kind of stuff will be the death of me

bright sphinx
#

ahah I mean you maybe learnt something when doing that 😂