NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
chaug
Aug 14, 2016Aspirant
Freeing up space on the OS partition (RAIDar 4.2.28, ReadyNAS Ultra 2)
From time to time (very rarely) my OS partition fills up to 100% causing all kinds of issues. Usually, the reason are some log-files that just became too big or too many. Once I had to move the Crash...
- Sep 20, 2016
Okay, so thanks to mdgm's assistance, it turns out that the files that were clogging up the OS partition were in /mnt/NAS2 where I had mounted another volume and to which Crashplan was writing its backup archives. The problem was that for mysterious reasons that volume disappeared from /etc/fstab and was no longer mounted. And as a result, Crashplan was writing to /mnt/NAS2 as a directory in the OS partition. I would never have thought that it is possible to write to /mnt/NAS2 when the volume is not mounted but apparently it is just an ordinary directory in those conditions.
In order to prevent that in the future, I am now mounting that external volume under the data partition instead of the OS partition,
StephenB
Aug 14, 2016Guru - Experienced User
I'd look in frontview and its subfolders next.
If you enter
cd //
ls -al
Then any folder that has a -> /c/... is a link to the data volume and can be ignored. You can also ignore c
chaug
Aug 15, 2016Aspirant
Aah, I should have guessed that everything that is nt /c/ would be the OS partition. Now I know. Thanks StephenB.
frontview is only 14 MB.
Will keep looking, but maybe that's just how much space the OS needs. Though I do seem to remember that it was much less last time I checked.
mdgm, yes, I have used du quite a bit, but du -h --max-depth=1
just gives me
16K ./lost+found 20K ./home 1.9T ./mnt 524K ./dev 0 ./sys
And then it becomes unresponsive and doesn't complete properly.
- mdgm-ntgrAug 15, 2016NETGEAR Employee Retired
The root usage shouldn't really get above 30 to 40%. The 4GB of space is way more than enough.
Keep looking.Don't look at /dev /proc /sys or /run
The problem won't be in one of those directories. It will be in one of the others.
- mdgm-ntgrSep 12, 2016NETGEAR Employee Retired
You have a mount for another NAS, showing a data volume that is 100% full. You shouldn't fill a data volume that full.
/usr/local/crashplan is using up 474MB. You may wish to move this to the data volume and create a symlink.- chaugSep 18, 2016Aspirant
This is driving me insane. Since you looked at the files, the OS partition has filled up to 100% again and I managed to get it down to 96% by deleting som stuff here and there, but none of the deleted files were recently added so they can't have been the cause of the partition filling up.
The stuff in /usr/local/crashplan is also not new. I have had crashplan running like this for years. - Yes, crashplan tends to eat some space over time due to its autoupdate funtion so I sometimes clean out the leftover files from the update processes, but that has been done already so there is no more stuff to delete. Even if I moved the whole thing to another partition as you suggest, I would only gain another 10 percent or so.
It's a mystery to me where this pile of data is hiding. Here are the sizes of all directories over 10 MB (excluding /dev /proc /sys and /run, which I did not look at according to the instructions above):
/usr = 779MB
/var = 163 MB
/etc = 190 MB (most of this space is used by /etc/frontview/addon/bin/EJRE/ejdkl.8.0_51)
/frontview = 14 MB
/opt = 28MB
/lib = 74 MB
I took a closer look at /usr:
/usr/lib = 247 MB
/usr/local = 271 MB
/usr/share = 137 MB
But even if I deleted all files in these branches, I would still not be at 30 or 40 percent.
All the branch sizes come from du -h
What else could I do?
- chaugSep 20, 2016Aspirant
Okay, so thanks to mdgm's assistance, it turns out that the files that were clogging up the OS partition were in /mnt/NAS2 where I had mounted another volume and to which Crashplan was writing its backup archives. The problem was that for mysterious reasons that volume disappeared from /etc/fstab and was no longer mounted. And as a result, Crashplan was writing to /mnt/NAS2 as a directory in the OS partition. I would never have thought that it is possible to write to /mnt/NAS2 when the volume is not mounted but apparently it is just an ordinary directory in those conditions.
In order to prevent that in the future, I am now mounting that external volume under the data partition instead of the OS partition,
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!