Selfhosted

39435 readers

3 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:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago

MODERATORS

[email protected]

Jellyfin on Proxmox (feddit.de)

submitted 1 year ago by [email protected] to c/[email protected]

42 comments fedilink hide all child comments

I want to use Jellyfin on Proxmox, if that is a thing. After reading a post here where most people recommended Debian as host OS I want to make a VM running Debian and install Jellyfin Server there.

Now I have a few questions:

I see many people install Jellyfin via docker. Does that have any advantages? I would prefer to avoid docker as it adds a level of complexity for me.
where do I save my media? I have a loose plan to run a second VM running openMediaVault where all my HDDs are passed through and then use NFS to mount a folder on the Jellyfin VM. Is that a sane path?
what do I have to consider on Proxmox, to get the best hardware results on Jellyfin? Do I need some special passthrough magic to get it running smoothly? I don't have a dedicated GPU, does that make the configuration easier?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago (1 children)

I wonder, after making these changes is it the same security wise as making the container unprivileged=0?

[–] [email protected] 1 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago

That makes sense. Thanks.