NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyNAS ultra6 shares not reachable / frontview does not persist changes
I am facing the same issue as several others here in the forum where the NAS has become unreachable and frontview does not persist changes anymore. I am guessing OS partition full. In the pas...
Verhodo wrote:I am facing the same issue as several others here in the forum where the NAS has become unreachable and frontview does not persist changes anymore.
I am guessing OS partition full.
That is most likely the case. It can be full space usage or less common (but still happens sometime) full of inodes.
Verhodo wrote:Is there anyone who can give me some information on what folders to check and what to delete to make space. Or which statements to run on the machine?
A common place to start is looking under /var/log on the 4GB root volume.
Verhodo wrote:PS: Rather bummed that NETGEAR is not providing a decent document on this.
I used to work for NETGEAR and have looked at a number of problems with these symptoms in the past. The issue is that every problem is different. I could write something easily that would work as more or less a best practice for a few common cases, but that wouldn't be very applicable in others. Doing the wrong thing can sometimes make a problem worse. Writing a good document that covers off pretty much everything would be a major undertaking.
A lot of threads here ignore some basic things that should be done like checking the health of the disks and the state of the RAID before starting the RAID. There's also syncing writes, unmounting the root volume and stopping the RAID properly when you're done as well.
First off thanks for your quick replies.
I just checked and managed to perform a df // -h which confirms that it is 100% in use.
The inodes are only 29% in use so I don't expect problems there.
In the /var/log/frontview there is a huge access.log file. As well as some others like command.log
in /var/log there is a cron.log and daemon.log and syslog which are also substantial.
Any pointers on how to clear space?
I am guessing (hoping :) ) this is a pretty standard case.
Again thanks for your help!
Verhodo wrote:
Any pointers on how to clear space?
echo -n > logfilename
will truncate the file to 0 size. Logfilename can include the full path, or you can use cd to enter the appropriate folder (cd /var/log for example).
You can truncate a couple of these (to get the OS partition below 50% or so), which will let you reboot. You can then clear the logs from frontview to shrink the rest.
Ok thanks.
I did this on some files but df -h keeps on telling 100%
Is there some kind of bin that keeps the files? I would expect a trunc like this to make space right away.
I tried rebooting in order to maybe free some file handlers or force a re-init, but the problem is still there.
I will try tonight if I can clear up some other files...
Tips & tricks are welcome :)
Plex is notorious for leaving behind scraps from transcoding that can be huge. A couple users have reported issues that seem to stem from an improperly mounted USB drive, so what should have just been a symbolic link to the drive, which is in the OS partition, was an actual directory and contained files intended for the USB drive. Other apps, especially anything you added via apt-get directly, could also be creating the problem.
But you have to be carefulo that you are really looking at a directory in the OS partition, not to something elsewhere via a symbolic link.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
