July 6, 20233 yr Greetings! Woke up to the follow this morning: Warning: session_write_close(): write failed: No space left on device (28) in /usr/local/emhttp/plugins/dynamix/include/.login.php on line 218 Warning: session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php) in /usr/local/emhttp/plugins/dynamix/include/.login.php on line 218 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/emhttp/plugins/dynamix/include/.login.php:218) in /usr/local/emhttp/plugins/dynamix/include/.login.php on line 222 After doing some searching/reading of forum posts looks like I have something writing to RAM which shouldn't be/something misconfigured. I've since restarted and am back in so not sure if the results of the df -h command will show anything of value but these are my current results: Filesystem Size Used Avail Use% Mounted on rootfs 63G 1.3G 62G 3% / tmpfs 32M 7.0M 26M 22% /run /dev/sda1 120G 886M 119G 1% /boot overlay 63G 1.3G 62G 3% /lib/firmware overlay 63G 1.3G 62G 3% /lib/modules devtmpfs 8.0M 0 8.0M 0% /dev tmpfs 63G 0 63G 0% /dev/shm cgroup_root 8.0M 0 8.0M 0% /sys/fs/cgroup tmpfs 128M 800K 128M 1% /var/log tmpfs 1.0M 0 1.0M 0% /mnt/disks tmpfs 1.0M 0 1.0M 0% /mnt/remotes tmpfs 1.0M 0 1.0M 0% /mnt/addons tmpfs 1.0M 0 1.0M 0% /mnt/rootshare tmpfs 64G 303M 64G 1% /tmp/PlexRamScratch /dev/md1 21T 20T 588G 98% /mnt/disk1 /dev/md2 21T 20T 640G 97% /mnt/disk2 /dev/md3 21T 20T 631G 97% /mnt/disk3 /dev/md4 19T 18T 736G 97% /mnt/disk4 /dev/md5 19T 17T 1.3T 94% /mnt/disk5 /dev/md6 15T 15T 540G 97% /mnt/disk6 /dev/md7 7.3T 7.0T 345G 96% /mnt/disk7 /dev/md8 7.3T 7.1T 236G 97% /mnt/disk8 /dev/md9 7.3T 7.0T 335G 96% /mnt/disk9 /dev/md10 7.3T 6.9T 430G 95% /mnt/disk10 /dev/md11 7.3T 7.1T 265G 97% /mnt/disk11 /dev/md12 7.3T 6.9T 421G 95% /mnt/disk12 /dev/md13 7.3T 7.2T 146G 99% /mnt/disk13 /dev/md14 21T 19T 1.3T 94% /mnt/disk14 /dev/nvme1n1p1 3.7T 611G 3.1T 17% /mnt/cache /dev/nvme0n1p1 1.9T 1.2T 657G 65% /mnt/plex /dev/nvme2n1p1 1.9T 3.8M 1.9T 1% /mnt/windows shfs 182T 175T 7.7T 96% /mnt/user0 shfs 182T 175T 7.7T 96% /mnt/user /dev/loop2 125G 66G 58G 54% /var/lib/docker /dev/loop3 1.0G 4.3M 905M 1% /etc/libvirt //192.168.0.10/Multimedia 50T 49T 1.4T 98% /mnt/remotes/192.168.0.10_Multimedia Appreciate any assistance in getting to the bottom of this and if I can provide any additional logs/screen shots let me know! Thanks!
July 6, 20233 yr Author Also output of du -xh --max-depth=1 / 0 /opt 884K /.cache 21M /tmp 1.2G /usr 23M /sbin 0 /mnt 30M /lib64 8.2M /lib 0 /home 15M /etc 12M /bin 12M /var 8.0K /root 1.3G /
July 6, 20233 yr Author Thinking it may be due to GUS (Grafana unRaid Stack) I setup this weekend? I've taken a look at my mappings and see telegraf is set to use map /rootfs to ram locations. Double checked instructions I had been following and these seem correct so may be not the issue? Maybe a more seasoned person can explain/confirm those mappings as well. Edited July 6, 20233 yr by Healzangels
July 11, 20233 yr Author Solution Issue occurred again this morning but was able to still access via ssh and find the culprit. Turns out it looks like a known bug currently with Plex Credit Detection. https://forums.plex.tv/t/plex-crashing-server-out-of-inodes-on-tmp/833431 will disable until a fix is in place. Hope this helps if anyone else has had this happen as well. Edited July 17, 20232 yr by Healzangels
July 15, 20232 yr On 7/11/2023 at 3:50 PM, ljm42 said: Why does a Plex Docker container have access to the server's /tmp directory?
July 16, 20232 yr RE: transcoding in RAM... Oh yeah, I ran like that for a while. Normally Docker containers are isolated from the system so the container can't hurt the host. If you override that by giving the container access to a system folder like /tmp, there is the chance that the container can cause problems for the host when something goes wrong. That is essentially what happened here, a problem with Plex filled up the system's /tmp folder and caused problems for the OS.
July 17, 20232 yr Author Yup, lesson learned! On 7/15/2023 at 8:37 PM, ljm42 said: Oh yeah, I ran like that for a while. Did you end up changing to a Nmve or something similar for your transcoding? Curious the pros and cons you've found if so. Well maybe besides the obvious on I've found myself with hah!
July 18, 20232 yr My Plex server only has 16GB RAM, with 4GB is allocated to CrashPlan and 4GB to an Unraid test VM... it basically started feeling too tight to let Plex take some of the remainder for transcoding. Not exactly a problem you have though : )
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.