UID/GID mapping breaking in-container UID/GIDS?

[flypenguin]

hi all, i am migrating to jellyfin as a kodi replacement, and for this i intended to use the following setup:

1. a jellyfin LXC backend (naturally), installed via community scripts
2. a "NAS" container to manage my files via web / SMB / ...
3. ... both accessing the same files on the host via bind mount.
4. the files on the host are mounted with nobody:nobody permissions, because there is no clear "owner" on the host system.

that might also be a template for further applications like ente, immich, ... . the diagram below shows the idea.

now the first milestone was to get jellyfin and the media access up and running, including the UID/GID mapping, so the required mapping is:

"HOST user nobody (65534:65534)" to "CONTAINER user jellyfin (107:110)"

Result: The mapping of the bind mount works, but now the UID of in-container files/directories is broken – jellyfin-owned files get mapped to "nobody"
(see "THE ERROR" below)

could anyone tell me why, or even better – how to "fix" this? because jellyfin will of course not run in this situation, and this feels like "that's not the way this is intended to be ...".

what i have unsuccessfully tried so far:

• pretty much any combination within the xxx.conf file, either the system won't start, or the mapping will not work. (of course maybe i missed the EXACT right combination, sure, i just tried a lot of them ... )
• adding "root:110:1" and/or "root:107:1" to /etc/set(u|g)id, but that did not help either.
• reading tons of blog posts about the subject

thanks in advance!
axel.


THE ERROR

# note the "nobody adm" uid/gids below
# WRONG UID
root@jelly:~# ll /var/lib/jellyfin -lad
drwxr-x--- 9 nobody adm 4096 Oct 17 21:43 /var/lib/jellyfin/

# after I REMOVING THE ID MAPPING from /etc/pve/lxc/...conf:
# CORRECT UID
root@jelly:~# ll /var/lib/jellyfin -lad
drwxr-x--- 9 jellyfin adm 4096 Oct 17 21:43 /var/lib/jellyfin/

THE PART WORKING

# WITH the uid/gid mappings, the bind-mounted directory shows up correctly:

root@jelly:~# ll /srv/media/
drwxr-xr-x 2 jellyfin jellyfin    6 Jan 16 22:01 Movies/
drwxr-xr-x 2 jellyfin jellyfin    6 Jan 16 22:01 TvShows/

root@jelly:~# ll -n /srv/media/
drwxr-xr-x 2 107 110    6 Jan 16 22:01 Movies/
drwxr-xr-x 2 107 110    6 Jan 16 22:01 TvShows/


# after REMOVING THE UID/GID MAPPINGS, the bind mount's UID/GID are, expectedly, incorrect again

root@jelly:~# ll /srv/media/
drwxr-xr-x 2 nobody nogroup    6 Jan 16 22:01 Movies/
drwxr-xr-x 2 nobody nogroup    6 Jan 16 22:01 TvShows/

root@jelly:~# ll -n /srv/media/
drwxr-xr-x 2 65534 65534    6 Jan 16 22:01 Movies/
drwxr-xr-x 2 65534 65534    6 Jan 16 22:01 TvShows/

THE CONF / SETUID / SETGID FILES

# xxx.conf
# non-important stuff removed
arch: amd64
# [...]
mp0: /srv/media,mp=/srv/media
lxc.idmap: u 0 100000 107
lxc.idmap: u 107 65534 1
lxc.idmap: u 108 100108 65428
lxc.idmap: g 0 100000 110
lxc.idmap: g 110 65534 1
lxc.idmap: g 111 100111 65425

# /etc/subuid
root:100000:65536
root:65534:1

# /etc/subgid
root:100000:65536
root:65534:1

THE SETUP

┌─────────────────────────────────────┐
│                                     │
│   ┌──────────┐    ┌────────────┐    │
│   │          │    │            │    │
│   │ Jellyfin │    │ "NAS" LXC  │    │
│   │          │    │            │    │
│   └┬─────────┘    └───────────┬┘    │
│    │uid/gid         uid/gid   │     │
│    │107:110         ???:???   │     │
│    │                          │     │
│    │                          │     │
│    │       nobody:nobody      │     │
│    │       65534:65534        │     │
│    └─────► /srv/media ◄───────┘     │
│                                     │
│    (Host-mounted media folder)      │
│                                     │
│Host                                 │
└─────────────────────────────────────┘

 

[flypenguin]

so yeah, i guess the solution is "this does not work this way", at least according to loooong chats with chatgpt and way too many tries and restarts.

it seems the second you bind the host's UID1 to a container's UID2, you apparently bind the container's _original_ UID2 to the hosts's UID1. (wha ... ? yeah, read a couple of times .

example:

• binding 1000 (host) -> 2000 (container) will apparently (correctly) let you show files owned by 1000 in the container by uid 2000.
• BUT AT THE SAME TIME apparently the container's original UID 2000 will now be 1000, so your uid 1000 user's home directory is no longer accessible for itself. which is ... i don't know what this is, i just know it is the opposite of "useful".

and should this be in fact the case I would find that utterly idiotic (i really cannot imagine any realistic scenario where this does not shoot you in the foot), BUT this is the only way I got this "working" at all. and chatgpt agrees. the documentation on the whole phenomenon is, to be frank, pure shit, or should in fact some useful documentation exist then the "findability" of it is.

BUT: I found no explicit sources for this, so I can be completely wrong. but I wanted to write something for other "me"s that are hitting that page from google, in the search, or whatever. because also frankly the available documentation for the whole topic is a pile of ...., and most of them have a common error with the subuid/gid files it seems.

if i indeed got it wrong and anyone can figure out a working solution for this, or an explanation why this in fact makes sense, i would highly appreciate a comment here or a message – because i truly do not see any actual practical use for such a seemingly strange mechanism except for some super niche use cases.