29
Jellyfin on Proxmox
(feddit.de)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 26 Oct 2023
29 points (87.2% liked)
Selfhosted
40219 readers
320 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
My experience with LXC hasn't been ideal, but for reasons that are by design. The permissions make it complicated for the way I use it. Proxmox has all of the storage, which is shared with the LXC as a Mount Point. The LXC has unique user PIDs and GIDs, so if the LXC modifies a file, now none of my other stuff has permission to access it.
I had to add some config stuff to get around this problem, but in the end I just switched to VMs. I don't care about overhead that much.
Edit to add more info: I think the permissions problem is only if you make the container "unprivileged". The relevant config to add to /etc/pve/lxc/***.conf is as follows:
I have no clue why this works. I think I copied it from Proxmox documentation. It worked and I left it at that.
The user and group mapping for lxc is easy(ish) once you understand it.
The above breaks out as follows: lxc.idmap: [user/group] [beginning host UID/GID] [number of sequential IDs to map]
lxc.idmap: u 0 100000 1000 [maps LXC UIDs 0-999 to host UIDs 100000-100999]
lxc.idmap: g 0 100000 1000 [maps LXC GIDs 0-999 to host GIDs 100000-100999]
lxc.idmap: u 1000 1000 1 [maps LXC UID 1000 to host UID 1000]
lxc.idmap: g 1000 1000 1 [maps LXC GID 1000 to host GID 1000]
lxc.idmap: u 1001 101001 64535 [maps LXC UIDs 1001-65535 to host UIDs 101001-165535]
lxc.idmap: g 1001 101001 64535 [maps LXC GIDs 1001-65535 to host GIDs 101001-165535]
The last two lines are needed because a running Linux system needs access to a minimum of 65336 UIDs/GIDs (zero-indexed).
You can basically think of LXC as running everything on the host system itself, but running it all as UID/GID 100000-65535 by default. In an unprivileged container, you have to remap these to give access to resources not owned by that range.
I wonder, after making these changes is it the same security wise as making the container unprivileged=0?
Nope. It just maps a single user and group from the container to a regular user on the host. With the above config, root in the container has the "real" UID of 100000. It can't make changes to anything any other unprivileged user can. A privileged container otoh runs root as root. It can do a lot of damage. By running privileged containers you're kind of throwing out a good portion of LXC's benefits.
That makes sense. Thanks.