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?

  • glasgitarrewelt@feddit.deOP
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    8 months ago

    The other comment made sense to me, why contain a container. But you are right, I will learn more about docker, it seems like a great tool.

    Thank you for your confirmation with NFS. Just read about it yesterday, in search of an alternative to samba, what all the windows user seem to use.

    • atzanteol@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      2
      ·
      8 months ago

      You “contain the container” because the VM provides storage and compute for docker (the docker container needs to run “somewhere”).

      I use a VM on proxmox to run a jellyfin container. VM mounts needed NFS dirs for config and media. Then create a systemd service to start/stop the container.

      • glasgitarrewelt@feddit.deOP
        link
        fedilink
        English
        arrow-up
        3
        ·
        8 months ago

        I understand that I can use a VM to run docker, but:

        Wouldn’t make a LXC more sense than a VM with docker inside? And what are the advantages of running jellyfin in a container instead of a normal installation? The VM is already kind of a container, what benefits do I get from yet another container inside? I am curious to learn more!

        • atzanteol@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          8 months ago

          Docker lets the maintainers configure all of the dependencies for you. You then don’t need to worry about whether you’re using debian, ubuntu or even fedora. When you upgrade jellyfin you just pick the new tag to pull without worrying about whether it needs a new version of ffmpeg or if it works with avconv.

          It gets you out of the business of trying to maintain compatibility and just keeping your os up to date.

          Feel free to use lxc though. I had issues with using lxc that I couldn’t work around so I use cloudinit ubuntu/debian images instead. I think the issue I had was actually using NFS but I don’t remember…

        • walden@sub.wetshaving.social
          link
          fedilink
          English
          arrow-up
          1
          ·
          8 months 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.

          • Revv@lemmy.blahaj.zone
            link
            fedilink
            English
            arrow-up
            3
            ·
            8 months 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.

              • Revv@lemmy.blahaj.zone
                link
                fedilink
                English
                arrow-up
                1
                ·
                8 months 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.