NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
InterClaw
May 31, 2015Aspirant
NAS not starting any services #25220444
I had a hard time coming up with a good subject for this problem, since I don't really know what's wrong and how to describe it. Here's the story: Suddenly I noticed that CIFS was not behaving norm...
InterClaw
Jun 01, 2015Aspirant
Thanks for your replies! If you're interested, I did a little more digging and thinking. :)
I found out that every time Crashplan starts it puts one of those jna1234567890123456789.tmp files of exactly 136883 bytes in tmp. They're definitely related to Java. From my googling it seems it might have to do with how Java is installed and that there might be a way to stop this from happening by unpacking some jar file to somewhere and pointing some config towards that instead. Well... not for me... :)
I'm not sure how such files could constitute 2.5GB though. That would be 18.000+ of them. Perhaps the files grow over time? Perhaps they are created at other times as well? Were there that many or of larger sizes in there? In any case, if deleted, Crashplan still works.
I did not find any specific temp path in the Crashplan config. Only for cache. The only references to "tmp" are for files/folders that should be hidden in the GUI I think so you don't select them for backup.
Right now the total Crashplan cache size is small, but I'll keep an eye on it in parallel with the tmp folder.
Would it be possible to force the creation of these jna*.tmp files on the data volume via some symbolic link or something? I found this, but I'm not sure I'm understanding it. Running what program?
http://stackoverflow.com/questions/1010 ... -io-tmpdir
I found out that every time Crashplan starts it puts one of those jna1234567890123456789.tmp files of exactly 136883 bytes in tmp. They're definitely related to Java. From my googling it seems it might have to do with how Java is installed and that there might be a way to stop this from happening by unpacking some jar file to somewhere and pointing some config towards that instead. Well... not for me... :)
I'm not sure how such files could constitute 2.5GB though. That would be 18.000+ of them. Perhaps the files grow over time? Perhaps they are created at other times as well? Were there that many or of larger sizes in there? In any case, if deleted, Crashplan still works.
I did not find any specific temp path in the Crashplan config. Only for cache. The only references to "tmp" are for files/folders that should be hidden in the GUI I think so you don't select them for backup.
Right now the total Crashplan cache size is small, but I'll keep an eye on it in parallel with the tmp folder.
Would it be possible to force the creation of these jna*.tmp files on the data volume via some symbolic link or something? I found this, but I'm not sure I'm understanding it. Running what program?
http://stackoverflow.com/questions/1010 ... -io-tmpdir
Dewdman42
Sep 03, 2015Virtuoso
I don't know how well this will work, but I just moved /usr/local/crashplan to /c/.crashplan and then created a sym link to it:
ln -s /c/.crashplan /usr/local/crashplan
Crashplan seems to be working ok that way
I did the same thing for the /tmp dir, moved it to /c/.tmp/ and sym linked to it. That one I am not as confident I won't run into some strange problem sooner or later, but I'm trying it for a while.
This should prevent either /tmp nor /usr/local/crashplan from ever filling up the root partition again.
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!