[Solved] [6.8.2] WebUI reports "no space" after authenticating

[dalgibbard]

Hey all,

My unraid server is showing the following after logging in to the WebUI. Any ideas what might cause this? I only get the initial login page, and then these errors immediately after logging in; so I can't administer the server at the moment.

 

```

Warning: session_write_close(): write failed: No space left on device (28) in /usr/local/emhttp/login.php on line 33

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/login.php on line 33

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/emhttp/login.php:33) in /usr/local/emhttp/login.php on line 35

```

 

Disk output as follows:

```

# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          3.8G  3.8G     0 100% /
tmpfs            32M  576K   32M   2% /run
devtmpfs        3.8G     0  3.8G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs           128M  380K  128M   1% /var/log
/dev/sda1       7.5G  386M  7.1G   6% /boot
/dev/loop0       22M   22M     0 100% /lib/modules
/dev/loop1      7.3M  7.3M     0 100% /lib/firmware
tmpfs           1.0M     0  1.0M   0% /mnt/disks
/dev/md1        2.8T  2.6T  172G  94% /mnt/disk1
/dev/md2        2.8T  2.6T  223G  93% /mnt/disk2
/dev/md3        2.8T  2.4T  363G  88% /mnt/disk3
/dev/nvme1n1p1  472G   70G  396G  16% /mnt/cache
shfs            8.2T  7.5T  756G  91% /mnt/user0
shfs            8.7T  7.6T  1.2T  87% /mnt/user
/dev/loop2       50G   16G   34G  31% /var/lib/docker
/dev/loop3      1.0G   17M  905M   2% /etc/libvirt

<Plus a bunch of docker stuff here>

```

 

Thanks for any advice!

Edited February 6, 2020 by dalgibbard

[dalgibbard]

Nevermind, found a failed user script had spammed /tmp/user-scripts/scriptname/log.txt

[Newbe999]

I have the same problem after the server runs for a day. What was the fix?

[trurl]

3 hours ago, Newbe999 said:

I have the same problem after the server runs for a day. What was the fix?

This is an old thread and there are various causes and fixes for something like this. 

 

Go to Tools-Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread 

[Newbe999]

I appreciate you taking a look at the attached file to figure out the issue.

Thanks

tower-diagnostics-20210327-1204.zip

Edited March 27, 2021 by Newbe999

[trurl]

3 hours ago, Newbe999 said:

a look at the attached file

According to your Diagnostics, your appdata share has some files on cache. But you don't have a cache drive.

 

One of your dockers must be specifying /mnt/cache/appdata, which will create that path in RAM since you don't have cache and anything written there will fill RAM and also won't persist after reboot.

[Newbe999]

Thank you, My dockers that have /mnt/cache/appdata specified what path should I change them too?

Maybe the default path specified by the docker?  

Will this work and will I lose any data for this docker?

[trurl]

2 hours ago, Newbe999 said:

what path should I change them too?

/mnt/user/appdata/...

 

2 hours ago, Newbe999 said:

will I lose any data for this docker?

 

2 hours ago, trurl said:

anything written there ... won't persist after reboot.

In other words, the appdata for those dockers that specify /mnt/cache will go away when you reboot anyway since for you that path is in RAM.

 

 

[ChatNoir]

9 hours ago, trurl said:

In other words, the appdata for those dockers that specify /mnt/cache will go away when you reboot anyway since for you that path is in RAM.

Would it be possible to move the files from RAM to the appropriate path ?