Limits on the location of /config for plex:docker

Plex Media Server Metadata & Adding Files
,
1

Server Version#: plexinc/pms-docker:plexpass

I’ve been trying to get a new docker setup going using a cifs volume mounted via docker. After many, many failures I started to guess that there was something in that folder that required either permissions of functions that just aren’t there in a cifs mount.

what I’d see is it register and act like it might work, but then never actually scan a library

So on that hunch I switched to an NFS mount which acts FAR more like an FS linux is used to. That worked, technically.

Now, however, it’s acting very very slow and just being a serious pain. And honestly can you say it’s working if it’s not useable? :smiley:

I suspect that there’s just too much going on for plex to work right with the network latency, and the best thing would be to use a passthrough folder on the docker host, and then run some side job to back it up. (I’m trying for db persistance even if my docker host craps out). Which is fine, I actually tried that earlier and it ran like a champ, but I was hoping to go All NAS so I stubbornly pushed through

I looked around but couldn’t find anything about this, (the docker repo doesn’t make any mention of it). Could someone say for sure what kind of limitations we should expect when placing the /config directory? I’ve got some ideas and theories, but would like to know.

Thanks!

2

Storing PMS data over NFS or CIFS isn’t supported for exactly the reasons you specify plus one big reason – database corruption.

There is ONE method you can use which will improve speed and guarantee file locking. iSCSI.

  1. Create the target & LUN on the NAS
  2. Setup the initiator on the Linux host to connect at system startup
  3. Mount before the container starts
  4. Have container look for its data through the ISCSI connection.

This works because it’s accessing as a block device and not file-based.
A different part of the kernel is being utilized; the correct part (block i/o)

1 Like
3

Makes total sense, thank you!

I hadn’t thought to look if iSCSI was an option (it is). Time to dig in and RTFM.

Thanks again!

4

Follow up:
iSCSI works WAY better than I had hoped for, I can’t really tell a difference from a local store and I’m running these experiments in an underpowered VM with 2 gigs of ram & 2 cores.

If anyone else out there is like me and been avoiding iSCSI because it’s kinda daunting, just eat your Wheaties, it’s totally worth it.

Thanks again for the tip @ChuckPa

5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.