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?

  • walden@sub.wetshaving.socialEnglish
    2·
    1 year ago

    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:

    unprivileged: 1
lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535

    I have no clue why this works. I think I copied it from Proxmox documentation. It worked and I left it at that.

    • RevvEnglish
      3·
      1 year ago

      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.

        • RevvEnglish
          1·
          1 year ago

          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.