Warning: file_put_contents(): Only -1 of 100 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php on line 714

What do you get from command line with this? 

df -h /

 

Hello, got the same problem.

df -h / : 

 

Filesystem      Size  Used Avail Use% Mounted on
rootfs           16G  1.8G   14G  12% /

 

After a reboot of the server, everything seems ok for me.

This is coming back after 24 hours or more of running. Does not cause any issues but annoying. 

 

See output below. 

 

df -h /
Filesystem      Size  Used Avail Use% Mounted on
rootfs           95G  2.2G   93G   3% /

attach diagnostics to your NEXT post in this thread

I am seeing the same issue on my unraid instance. I see /run at 100%

 

Filesystem              Size  Used Avail Use% Mounted on
rootfs                   40G  2.2G   38G   6% /
tmpfs                    32M   32M     0 100% /run
/dev/sda1               7.5G  1.1G  6.4G  14% /boot
overlay                  40G  2.2G   38G   6% /lib/firmware
overlay                  40G  2.2G   38G   6% /lib/modules
devtmpfs                8.0M     0  8.0M   0% /dev
tmpfs                    40G     0   40G   0% /dev/shm
cgroup_root             8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs                   128M  4.3M  124M   4% /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/rootshare
/dev/md1                2.8T  2.1T  690G  76% /mnt/disk1
/dev/md2                2.8T  1.9T  907G  68% /mnt/disk2
/dev/md3                2.8T  2.8T   13G 100% /mnt/disk3
/dev/md4                1.9T  868G  995G  47% /mnt/disk4
/dev/md5                1.9T  379G  1.5T  21% /mnt/disk5
/dev/md6                1.9T   14G  1.9T   1% /mnt/disk6
/dev/md7                1.9T   14G  1.9T   1% /mnt/disk7
/dev/md8                1.9T   14G  1.9T   1% /mnt/disk8
/dev/md9                1.9T   14G  1.9T   1% /mnt/disk9
/dev/md10               1.9T   14G  1.9T   1% /mnt/disk10
/dev/md11               1.9T   14G  1.9T   1% /mnt/disk11
shfs                     23T  8.0T   15T  35% /mnt/user0
shfs                     23T  8.0T   15T  35% /mnt/user
/dev/loop2               20G   12G  8.0G  60% /var/lib/docker
/dev/loop3              1.0G  4.1M  905M   1% /etc/libvirt

On 2/1/2023 at 8:29 AM, trurl said:

attach diagnostics to your NEXT post in this thread

 

Logs attached

unraid-diagnostics-20230222-1636.zip

I have the same problem on version 6.11.5.

 

Reboot and it goes away but it comes back eventually.

Diagnostics would be necessary

Started getting the same error last night. 

 

Running "df -h" shows this:

 

root@LIBRARY:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs           16G  3.7G   12G  24% /
tmpfs            32M   32M     0 100% /run
/dev/sda1       7.7G  668M  7.0G   9% /boot
overlay          16G  3.7G   12G  24% /lib/firmware
overlay          16G  3.7G   12G  24% /lib/modules
devtmpfs        8.0M     0  8.0M   0% /dev
tmpfs            16G     0   16G   0% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs           128M   33M   96M  26% /var/log
/dev/md1         13T  9.7T  3.2T  76% /mnt/disk1
/dev/md2         13T  9.6T  3.2T  76% /mnt/disk2
/dev/md3         13T  9.6T  3.2T  76% /mnt/disk3
/dev/md4         13T  9.6T  3.2T  76% /mnt/disk4
/dev/md5         13T  8.3T  4.5T  65% /mnt/disk5
/dev/md6         13T  6.4T  6.4T  51% /mnt/disk6
/dev/md7         13T  6.5T  6.3T  51% /mnt/disk7
/dev/md8         13T  6.4T  6.4T  51% /mnt/disk8
/dev/md9         13T  6.4T  6.4T  51% /mnt/disk9
/dev/md10        13T  6.4T  6.4T  51% /mnt/disk10
/dev/sdf1       932G  252G  678G  28% /mnt/cache
shfs            128T   79T   49T  62% /mnt/user0
shfs            128T   79T   49T  62% /mnt/user
/dev/loop2       20G  9.9G  9.6G  51% /var/lib/docker
/dev/loop3      1.0G  4.1M  905M   1% /etc/libvirt
 

Disk, RAM, and flash drive have plenty of space. Did anyone resolve this yet? 

CA-Logging-20230326-1034.zip

Edited March 26, 20233 yr by limitz

21 minutes ago, limitz said:

Did anyone resolve this yet? 

Without knowing exactly what page you were on (ie: context) and your diagnostics its very hard to say what the cause actually is

On 3/26/2023 at 11:56 AM, Squid said:

Without knowing exactly what page you were on (ie: context) and your diagnostics its very hard to say what the cause actually is

Same problem here. Attached diagnostics. Comes up every few months requiring me to reboot the server

param-diagnostics-20230413-0109.zip

Same here. It's on the plugin's tab for me. Uptime at the moment is 20 days. Iirc it was due to this message that I rebooted last time. Both times so far for me, the status for all plugins states "not available"

trinity-2-diagnostics-20230523-1655.zip

Same issue here, on most pages 

Warning: file_put_contents(): Only -1 of 173 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php on line 714

As far as I can tell, it's not affecting anything else, no issues with plugin/updates.  I've attached diagnostics as well.

 

root@Pantainos:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
rootfs           16G  2.2G   14G  14% /

 

 

pantainos-diagnostics-20230526-1105.zip

tmpfs is full

 

Filesystem      Size  Used Avail Use% Mounted on
tmpfs            32M   32M     0 100% /run

 

Same issue here. Have this error on every page in UnRaid GUI and when I get the message, the "my servers" API stops working also. I reboot my server and it's all fine. Not sure what the issue may be... 

 

diagnostics-20230603-1752.zip

Edited June 3, 20233 yr by SpaceKeat

On 5/26/2023 at 1:20 PM, JorgeB said:

tmpfs is full

 

Thank you, but I guess I'm a noob with this. Is there a way to clear or expand the tmpfs while the server is running, or do I have to reboot to resolve? 

Edited June 4, 20233 yr by SpaceKeat

I found this sort of solution here. UnRaid Form Could I just resize my go script to more than 32M and would this alleviate the issue? 

The default size of 32M should be more than enough unless an application is mis-behaving     Looking at the contents of /run might give you a clue as to the culprit.  Making it larger would just delay the issue occurring, not fix the problem.

In my case I found that the plex docker was flooding the log with useless info logs. For now I solved restarting the plex docker every 12hours with user script

On 6/4/2023 at 3:55 AM, GrimorioTech said:

In my case I found that the plex docker was flooding the log with useless info logs. For now I solved restarting the plex docker every 12hours with user script

Definitely Plex.  Stopped my server and my /run usage dropped to next to nothing.  Going to turn off debug logging (which is on by default) and see if that makes a difference.

I found I have that Plex debug logging on too! nice find. I'll turn this off and see if there are any improvements. If I don't reply, that was it

Edited June 5, 20233 yr by SpaceKeat