Since adding new HDDs and resyncing, I've been getting the following error message:
Volume: System volume root's usage is XX%. This condition should not occur in normal conditions. Contact technical support.
It started at 81%, increased in 1% increments to 85%, and then fell to 84% — all over the course of about four days. The messages are appearing in the logs every ten minutes, and I'm getting alert e-mails with the same frequency.
I contacted tech support but there has been silence after creating the ticket. My 314 has just been sitting in diagnostic mode for the past 24+ hours with no word on whether or not they have identified the cause or a solution.
There are some other posts on this topic in the forums, but they seem related to specific apps (Logitech Media Server, Crashplan, btsync). Is there a "universal" way to go about identifying what might be eating up so much space in the 4GB rootfs partition? And what exactly constitutes the rootfs partition — everything but "data"?
I sent @mdgm-ntgr a PM, too, but haven't heard anything.
About 1GB of the 4GB OS partition is being used by the LMS app alone.
# du -csh /var/lib/squeezeboxserver
691M /var/lib/squeezeboxserver
691M total
# du -csh /usr/share/squeezeboxserver
307M /usr/share/squeezeboxserver
307M total
When apps store a lot of data on the OS partition that does contribute to getting error messages like this. There are a few other things as well that have contributed to the high root volume usage.
The usage going up then down then back up again would relate to log truncation/pruning presumably.
Most things that are not stored on the data volume would be stored on the root volume.
Thanks, @mdgm-ntgr. Besides LMS, what exactly is taking up so much space? And is there anything that can be done about it?
I saw in one of the other threads the SSH shell command for moving the LMS cache to data. Is there anything else that I can do to get data out of rootfs?
I don't know how to identify what's taking up space. Terminal commands aren't my strong suit. Is there a way to ID large files through SFTP? How can I remedy this issue? I'm happy to do the work; I just need some advice and instructions.
Also, I don't know if data is always mounted before LMS starts. The 314 shuts down every night and starts up every morning, and LMS is always set to "On." Does this pose a potential problem?
Sarcasm aside, I don't know what to do. Via SFTP I just deleted some "uemediaserver" folders that I suspect are no longer in use, and I deleted the "Mobile Photos" library from my Plex Media Server (along with all the photos it contained) and the alert messages stopped. So I guess it's at least reduced to non-critical levels.
The du command is great, but I don't even know how to execute it properly in this case.
And if I move mysql and LMS to data, will they now appear as shares?
Yesterday Netgear Support e-mailed me the following instructions:
1. Turn off the RN314 2. Remove disk 2,3 and 4 in the chassis and keep just disk1 (HDDs from RN104) 3. Reset the RN314 to factory defaults with only disk1 4. Once the NAS boots up normally, go to storage and disable XRAID by clicking on the icon 5. Once XRAID is disabled, insert all the 3 disks we took out earlier in order (disk2,3 and 4) 6. Then go to Settings and enabled Support Diagnostics and provide me the 5-digit code
Good thing I queried some of the details. It was for an entirely different case. I'm not sure what's worse, silence or misinformation.
So I took matters into my own hands and began shifting Logitech Media Server files out of rootfs because LMS has definitely been identified as too space-hungry. I need to move my mysql directory, too, but that's tied to Netgear's Contacts and Calendars Server (i.e., Baïkal), which cannot be switched "off" from the GUI, so I have no idea how to kill it so I can move the files to /data.
The other thing is that I have no idea how to assess the current size of rootfs, since it's not appearing when I use the "df -h" command. This is the output:
