I recently had my root filesystem full (for reasons unknown to me). Consequence from that, I could not access my shares anymore and the webgui was gone with only a message left like =>
"no wixnas object found"
I tried to save some disk space from / but df commmand was still reporting rootfs as full and I could not find where this mysterious disk usage sucked all my free space… I tried to reboot the NAS couple of times (bad idea…) Then I found out that the file /proto/SxM_webui/admin/config.xml was empty (null size). Reading this forum, I've learnt that I could recover this file from the WD source files available (which I had already downloaded long ago) from WD website.
So I recovered the config.xml file like =>
tar zxf /root/WD-MyBookWorld-v1.01.14-GPL/sources/1nc_sources-20091015.tar.gz webgui/admin/config.xml -O > /proto/SxM_webui/admin/config.xml
The webgui was then available after a page refresh in my browser but now I still have to reconfigure my personal shares so they can be seen… (on my todo list, not a big deal)
The reason why I am telling you all of this is because I think it might have been a bad idea to restart my NAS… Later on, after some googling, I realised that there is most propably this possible root cause to fs full =>
The problem manifested itself when a 'df' command showed a filesystem at 100%, but this did not match the total value of a 'du -sk *'.
When this happens, the process continues to write to the file but you can no longer see the file on the filesystem. Stopping and starting the process will, more often than not, get rid of the unlinked file, however this is not always possible on a live server.
When you are in this situation you can use the 'lsof' command above to get the PID of the process that owns the file
Here is another very good explanation of this filesysteme behavior (open file descriptor) =>
Conclusion : In case you get a rootfs full status, then run this command =>
So you can find out which open file descriptor you have and kill the related process owning it. Here is a sample output from this lsof command =>
COMMAND PID USER FD TYPE DEVICE SIZE NLINK NODE NAME a-proc 23521 root 3u REG 8,1 5595979 0 353398 /some/logfile (deleted)
Of course, I have no idea if it would have prevented all the previous issues and how come /proto/SxM_webui/admin/config.xml was empty… I wonder if I still have some other important system files lost from these rootfs full and NAS restarts :-(
I just thought I would take the time to write to you my experience here. I hope it can bring help to someone some day when finding this thread ;-)
HF & GL