Healzangels Posted July 6, 2023 Share Posted July 6, 2023 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! Quote Link to comment
Healzangels Posted July 6, 2023 Author Share Posted July 6, 2023 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 / Quote Link to comment
Healzangels Posted July 6, 2023 Author Share Posted July 6, 2023 (edited) 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, 2023 by Healzangels Quote Link to comment
Solution Healzangels Posted July 11, 2023 Author Solution Share Posted July 11, 2023 (edited) 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, 2023 by Healzangels Quote Link to comment
ljm42 Posted July 11, 2023 Share Posted July 11, 2023 Why does a Plex Docker container have access to the server's /tmp directory? Quote Link to comment
JonathanM Posted July 15, 2023 Share Posted July 15, 2023 On 7/11/2023 at 3:50 PM, ljm42 said: Why does a Plex Docker container have access to the server's /tmp directory? Quote Link to comment
ljm42 Posted July 16, 2023 Share Posted July 16, 2023 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. Quote Link to comment
Healzangels Posted July 17, 2023 Author Share Posted July 17, 2023 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! Quote Link to comment
ljm42 Posted July 18, 2023 Share Posted July 18, 2023 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 : ) Quote Link to comment
Recommended Posts
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.