Migrating from Plex plugin to docker Plex server

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Migrating from Plex plugin to docker Plex server

      Ok, I'm trying to move my Plex setup from the (old not any more updated) Plex server plugin to a docker container, I'm able to get Plex up and running via the docker container and see my old server BUT all of my libraries are gone! What must/can I do to fix this? I'm running on a raspberry PI.
    • OMV + Docker plugin media server (Plex, PlexPy, Ombi, Libresonic, NZBGet, ruTorrent, Sonarr, Radarr, Mylar, and more)

      Did you follow post 3?

      It sounds like you've not added your data folders/container path configurations correctly if it's not seeing anything. You gotta tell the docker where to look or Data.

      Edit: One thing to make sure on with Docker (and especially with Plex) is to make sure have configured the Docker plugin to store your containers in a folder on your Data drives. Otherwise you will be posting here tomorrow about how you can't log in to the webUI and are getting an error your system drive is full.
      Air Conditioners are a lot like PC's... They work great until you open Windows.

    • insickin wrote:

      You mean my config path?
      That refers to the plexmediaserver folder that the old plugin made
      Not really, but if you've got your plex folder off of the SDcard, that's the most important thing. I'm just not a fan of keeping my containers on the SDcard/OS drive either.

      It's probably fine, but if you start running a lot of containers and have a smallish SD card, it might be an issue.

      Click Docker/Settings and if the drop down box is set to "None".. then your containers are being stored onthe SD card. You can create a folder on your data drives, and store all your containers there.
      Air Conditioners are a lot like PC's... They work great until you open Windows.

    • KM0201 wrote:

      Click Docker/Settings and if the drop down box is set to "None".. then your containers are being stored onthe SD card. You can create a folder on your data drives, and store all your containers there.
      I had that changed when I installed Docker so no files on my SD card! I knew that that could fil up my SD card fast!

      For the time being I reverted back to the old plugin, The strange thing is that it has been miraculously updated to the latest version of Plex server after my Docker adventure.... :huh: Now time for some sleep.

      The post was edited 1 time, last by insickin ().

    • insickin wrote:

      gderf wrote:

      No. The directories that hold your movies, music, and TV shows. These are pointed to by the Container path /data
      I have them pointed like so:
      Host path:
      /sharedfolders/Drive1

      Container path:
      \Drive1

      Am I doing something wrong? ?(
      That would probably work.. are you looking under "Drive1" in the Plex web setup? Since that is where you're mapping it, that's where you need to look.
      Air Conditioners are a lot like PC's... They work great until you open Windows.

    • I do not use OMV created Sharedfolders for Docker Host paths. I use the absolute fully qualified filesystem directory names, and the permissions and ownerships are initially set by hand in the shell if needed. You should ensure that any process that writes files and directories that are to be used within Plex have the correct ownership and permissions such that Plex can operate on them.

      Using Container paths not defined in the image documentation can lead to unpredictable results (your Container path: \Drive1). I suggest NOT doing this.

      Also, the permissions and ownership on your media files and directories, as well as the Host path directory defined by the /config Container path have to be proper for the container process to be able to enter the directories and read the files. For the /config and /transcode Container paths, the referenced Host paths must be readable and writable by the user the Plex container runs as. Same for the Host path directory referenced by the /transcode Container path, and additionally it must be located on a drive that is mounted with the exec option.

      99% of all problems with Plex Media Server, including docker implementations, can be traced to improper permissions and ownership of the the files and directories the service has to interact with. This can not be overstated.
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • I dunno, to me you kinda kill the advantage of Kodi playing directly from SMB or NFS, then add the overhead of Plex on top of it. Just doesn't make sense to me.

      Set up an SMB/NFS share
      Map Kodi to said share.
      Scan the directory with the appropriate scraper, to import all the metadata to Kodi.

      Piece of cake, no running additional server processes, etc.
      Air Conditioners are a lot like PC's... They work great until you open Windows.

    • gderf wrote:

      I do not use OMV created Sharedfolders for Docker Host paths. I use the absolute fully qualified filesystem directory names, and the permissions and ownerships are initially set by hand in the shell if needed. You should ensure that any process that writes files and directories that are to be used within Plex have the correct ownership and permissions such that Plex can operate on them.

      Using Container paths not defined in the image documentation can lead to unpredictable results (your Container path: \Drive1). I suggest NOT doing this.

      Also, the permissions and ownership on your media files and directories, as well as the Host path directory defined by the /config Container path have to be proper for the container process to be able to enter the directories and read the files. For the /config and /transcode Container paths, the referenced Host paths must be readable and writable by the user the Plex container runs as. Same for the Host path directory referenced by the /transcode Container path, and additionally it must be located on a drive that is mounted with the exec option.

      99% of all problems with Plex Media Server, including docker implementations, can be traced to improper permissions and ownership of the the files and directories the service has to interact with. This can not be overstated.
      @gderf
      I feel like I stumbled across gold here. Pardon my OMV ignorance, I'm really trying to learn and to set things up the right way. I'm no stranger to virtualization, but am very new to containers.

      A few questions if you have the time.
      1. "I do not use OMV created Sharedfolders for Docker Host paths. I use the absolute fully qualified filesystem directory names..." I don't see another way to apply permissions to folders in OMV w/o exposing them as a file share. Can you explain further or just point me to some relevant documentation regarding this rule?
      2. Is this a general rule, or a best practice you've developed for yourself?
      3. I see a lot of videos for installing specific containers, but I'm not having much luck finding any general guidelines for containers in OMV (lots of threads of specific problems though).
      4. "the referenced Host paths must be readable and writable by the user the Plex container runs as" does OMV have a default user for running containers or is this specified in an environment setting, or is this specific to each container itself?
      Thanks so much!
      Off-Grid Home Server Project:

      ROCKPro64 4GB (Rockchip RK3399 Hexa-Core) running OMV 4.1.21-1(Arrakis)
      16GB eMMC [OS]
      PCIe 2.0 to 4 Port SATA 3.0 (Marvell 88SE9215)
      120GB cheapo 3D NAND SSD [user store, containers, etc]
      2-1TB 860 EVO SSD RAID1 [media store]
      PINE64 NAS enclosure
      TP-Link AC750 (TL-WR902AC) [wireless access]
      Currently hosting Plex Media Server

      ~9 watts power consumption
    • 1. There can be differences between the permissions of file shares and the permissions on the actual filesystem entities. For example, you might define an OMV file share named test which points to an actual directory on the file system /srv/disk-label/some-directory-name. The permissions and ownership of of these two entities might be different. You can always set permission and ownership of /srv/disk-label/some-directory-name in the shell with chmod and chown commands. You may be limiting yourself by relying only on that which you can accomplish via the OMV GUI rather than what can be accomplished in the shell.

      2. I see a fair number of forum posts about permission, ownership, and race condition problems related to OMV defined shared folders when these are referenced in things like docker volume and bind mounts. I don't seem to have these problems. Maybe that's because I don't use shared folders that way. I use absolute fully qualified filesystem names instead wherever possible. There are some things that require a shared folder definition because that is the only way a required item will appear in a OMV GUI item's drop down selection list.

      3. The available guides are a good resource. But they also present their authors' individual usage styles and might not fully explain what they are doing, or make what I call silent assumptions. I find the actual container documentation to be highly useful and generally clearer than a lot of the guides I have seen.

      4. Most container images have some form of user and group environment variable definitions that can be used to define the user:group context that the container runs as. Most frequently seen as PUID and PGID. You set these to numerical values of an actual user and group that exist on the system. For example, I am user fred who belongs to the users group. The user number for fred on my system is 1001 and the users group number is 100. So in my docker environment variable table I have PUID 1001 and PGID 100. This forces the container to run as that user and group. And if the files and directories that the container talks to have the same user and group ownership and the appropriate permissions, everything just works. If PUID and PGID (or similar variables) are not specified or not supported by the container, then some default user and group are used, and using these can result in unpredictable behavior. Whenever I begin using a docker that is new to me I always read the documentation for it fully.
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380