Server Version#: 1.31.3.6868
Player Version#: n/a
As stated. Server indicates all is well with remote access, local access is good. However, neither app.plex.tv nor any remote clients can connect to the server. app.plex.tv reports “Unable to connect to “” securely.”
Everything was functional this AM(EDT) 01 Apr 2023
Make certain PMS DEBUG logging is enabled / VERBOSE logging is disabled & SAVE
Restart PMS.
Wait 1 minute for it to stabilize
Now go into Plex/web and Tickle the Remote Access.
Wait for it to do its thing
Now download Server logs ZIP and attach here please
Plex Media Server Logs_2023-04-01_22-17-30.zip (2.2 MB)
As instructed
I’ve found a couple issues:
Plex.tv has throttled your certificate requests (exceeded quota). It’s refusing to issue a new certificate until the issue is corrected.
The directory structure in your “Plex Media Server” directory for the container failed because of this.
Apr 01, 2023 16:20:13.809 [0x7fe22be86b38] ERROR - IsDirectory failed boost::filesystem::status: Socket not connected: “/config/Library/Application Support/Plex Media Server/Media/localhost/2”
Apr 01, 2023 18:17:14.040 [0x7f65d3756b38] INFO - Plex Media Server v1.31.3.6868-28fc46b27 - Docker Docker Container (LinuxServer.io) x86_64 - build: linux-x86_64 debian - GMT -04:00
Apr 01, 2023 18:17:14.041 [0x7f65d3756b38] INFO - Linux version: 6.2.8-060208-generic, language: en-US
Apr 01, 2023 18:17:14.041 [0x7f65d3756b38] INFO - Processor: 48-core Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
Apr 01, 2023 18:17:14.041 [0x7f65d3756b38] INFO - Compiler is - Clang 11.0.1 (https://plex.tv 9b997da8e5b47bdb4a9425b3a3b290be393b4b1f)
Apr 01, 2023 18:17:14.041 [0x7f65d3756b38] INFO - /usr/lib/plexmediaserver/Plex Media Server
Apr 01, 2023 18:17:14.059 [0x7f65d39f3aa8] ERROR - [CERT] d2i_PKCS12_bio failed: error:0200B015:system library:fread:Is a directory
Apr 01, 2023 18:17:14.059 [0x7f65d39f3aa8] ERROR - [CERT] Found a user-provided certificate, but couldn’t install it.
I need to ask:
Does the PUID/PGID (PLEX_UID/PLEX_GID) properly own everthing where /config points in the real file system ?
If so, looking at /config/Library/Application Support/Plex Media Server/Cache,
cert-v2.p12 present and also writeable (644) ?The logs from Plex.tv show me 14 new certificates were issued since March 16.
The 15th certificate request was the trigger.
You normally need one certificate every 90 days.
I can reset the certificate for you but, unless the directories and files where the container is stored are corrected, this will reoccur.
Roger Roger
That’s from an issue I’ve been having with mergerfs. Occasionally, the mount will crash. Still working on it with the dev. When the mount is up the directory structure is sound.
I briefly tried to configure a custom cert when it was telling me that a secure connection could not be established. Initially I had configured it incorrectly by setting the file path as just the cert directory instead of the full path the the specific file. I gave up that approach soon after trying it and those fields are now blank.
Answers:
Yes the container is set to be 1000:1000 and the entire directory is set 1000:1000 with 755/644 permissions.
This is where this is probably all my fault. My cache dir was about to eat up every bit of my spare space on the partition hosting it. In rearching the issue I came across a suggestion to put the cache dir in a tmpfs. So I mounted a 4G tmpfs at Cache and have been running that way for the last couple weeks. The cache dir was owned root:root but was 777 for permissions. If that cert file is kept in Cache, then that definitely explains why I have been issued so many certs. In dealing with the mergerfs issue I mentioned, I have had quite a few reboots in the last couple weeks.
I have now removed the tmpfs mount. If that is indeed where the cert is stored, I would greatly appreciate a reset.
Now I just need to find a way to keep the cache from filling that partition. I run all my container configs off my SSD and have the Plex Media directory bind mounted off to my storage array to keep it from filling the SSD. Perhaps doing the same with cache is in order.
Thank you for your assistance! If you have any alternative suggestions please let me know.
You’ve got your PMS metadata directories on some artificial constructed / network constructed file system? – HIGHLY prone to failure.
– Recommend finding a place on a real , monolithic, file system.
Setup a cron job to weekly stop PMS and purge it. PMS doesn’t expire it for some 90-120 days (of complete idle) which means – effectively never.
Delete it yourself, Run the fstrim, you’ll be much happier. ( many of us do this )
How tough to get you back on a real volume so I can get you running again? 
So the Media dir is on the same system. I have the SSD that has the rootfs, my docker config files, home dir, etc etc. Then I have an 8 HDD array on the same system that I use mergerfs/snapraid on to appear as a single file system ~100TB. The Media dir is just bind mounted from the SSD to a directory on the mergerfs mount. Metadata and thumbnails for 3200+ movies and 14,000+ episodes was just eating up way too much of the 500GB SSD. Up until the mergerfs crashes started a couple weeks ago, the setup was great
Cache is now back on the SSD instead of tmpfs and I’ll definitely be setting up some type of cleanup job. As for the media dir, it’s grown beyond what I can store on the SSD. I’m a little reluctant to move the entire /config mapping to one of the storage pool drives.
It is not a good idea to place the Plex metadata directory (its docker /config) on a mergerfs array.
If you have video preview thumbnails enabled in Plex you can expect its metadatabase to become very large - several hundred GB is not unusual.
Everything but that one directory, Media, is on the SSD. And yes, I have preview thumbnails enabled, that’s why I ended up going this route. I thought about symlinking the Media directory but the container can’t follow it as it points outside its volume mapping. The option I’m reluctant doing is mapping PMS’ entire docker /config to one of the individual drives from the array. I don’t know, maybe this pushes me to add a 2TB SSD to the system.
If I may make a suggestion?
Rather than mergerfs, why not use a native ‘bind’ mount
if you do it by hand `mount -o bind /real/dir /mounted/on/dir’
Example:
# create location for it
mkdir /home/plex/Metadata
chown plex:plex -R plex:plex /home/plex
# Move the "Plex Media Server/Metadata" directory -> /home/plex/Metadata
cd "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server"
mv Metadata/* /home/plex/Metadata
# Now you can mount
mount -o bind /home/plex/Metadata "/var/lib/plexmediaserver/Application Support/Plex Media Server/Metadata"
This can be flattened by a system override and specifying a flatter “Application_Support_Dir” path
In /etc/fstab, it looks hokey but works. (octal spaces)
/home/plex/Metadata /var/lib/plexmediaserver/Application\040Support/Plex\040Media\040Server/Metadata none bind 0 0
There are no symlinks to get tripped up on. No dependencies on other software.
Everything is native in the kernel.
(bind is used in ‘chroot’, containers, and vms)
Play with this first. Make some test cases and see it in action.
That is exactly what I’m using. Except my mount point is within the mergerfs directory. Here’s the relevant section in my fstab.
## MergerFS DataPool Disks
UUID=<UUID> /blackbeard/datapool/D20T-2LGET20K ext4 defaults 0 2
UUID=<UUID> /blackbeard/datapool/D20T-8LGPH8LL ext4 defaults 0 2
UUID=<UUID> /blackbeard/datapool/D18T-2JJGX21B ext4 defaults 0 2
UUID=<UUID> /blackbeard/datapool/D18T-2VH13NKA ext4 defaults 0 2
UUID=<UUID> /blackbeard/datapool/D16T-2MKV4WWG ext4 defaults 0 2
UUID=<UUID> /blackbeard/datapool/D16T-3JHB212G ext4 defaults 0 2
UUID=<UUID> /blackbeard/datapool/D16T-5DJPA43J ext4 defaults 0 2
## SnapRAID Parity Disks
UUID=<UUID> /blackbeard/parity/P20T-2LGENMTF ext4 defaults 0 2
## MergerFS ./data unionFS
/blackbeard/datapool/D* /blackbeard/data fuse.mergerfs defaults,use_ino,allow_other,noforget,async_read=false,read-thread-count=0,inodecalc=path-hash,fsname=data_pool,category.create=pfrd,cache.files=auto-full,cache.writeback=true,cache.symlinks=true,cache.readdir=true,cache.entry=120,cache.attr=120,cache.statfs=10,dropcacheonclose=true,moveonenospc=true 0 2
## NFS bind mount for /data share
#/blackbeard/data /srv/export/data none bind 0 0
## bind mount plex media from data array to plex dockerdir
/blackbeard/data/media/plex-media /docker/data/plex/Library/Application\040Support/Plex\040Media\040Server/Media none bind 0 0
## plex ramdisk for PhotoTranscode ***delete ./PhotoTranscode/* before activating***
#tmpfs /docker/data/plex/Library/Application\040Support/Plex\040Media\040Server/Cache tmpfs rw,size=4G 0 0
The tmpfs mount I had been using for the Cache dir is there at the bottom and commented out to disabled.
And then this is my docker volume section for Plex:
volumes:
- $DOCKERDIR/plex:/config
- $DATADIR/media:/data
- /dev/shm:/transcode
$DOCKERDIR=/docker/data
$DATADIR=/blackbeard/data
The other thing I want to mention is that having your Plex docker /config bind mount being within the realm of SnapRAID is not a good idea. You should exclude that location in the snapraid.conf file.
The /cofing is indeed not part of the snapraid sync. /config itself is on a separate SSD and the Media directory I redirect to the Snapraid covered disks is marked as exclude in the snapraid.conf
I think I may have been confusing this issue by my interchanging use of “bind mount”.
to clarify:
Linux bind mount:
This is the linux “bind mount” that @ChuckPa mentioned and that I am using to redirect the PMS ./Media directory to my storage array with a line in my fstab
Docker bind mount:
This is the Docker™ distinction between the two ways to mount a volume in a container.
##Docker volume mount
volumes:
docker_volume_name:/<container directory>
##Docker bind mount
volumes:
/docker_directory_on_filesystem/plex:/config
the first being effectively “hidden” within docker’s tooling, and the second showing up as just another user directory on the system,.
For me the decision was easy. I saw little value of preview thumbnails and abandoned them, and deleted them when they caused my Plex database to swell to more than a ridiculous 250GB.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
