NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
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 normally. I could browse shares, but not add any files.
This can of course be because of a million things, so I figured I try disabling and enabling that service in RAIDiator (4.2.27). So I disabled it and tried enabling it again, but selecting that service and clicking apply does absolutely nothing. The checkbox disappears and nothing more happens. No error message. Weird...? FTP still worked though, at least for browsing.
So I restarted the NAS. Then the CIFS service was still off and can't be started and the shares (naturally) disappeared from the network. Uh?! Not only that, but FTP had disabled itself. And, yeah, it won't start either. SSH had stopped working. Addons like Transmission as well won't start. I have Crashplan running on it, which I can't access either, so I don't really know if that starts or not.
Browsing via HTTPS still works, so the volume and the shares are still there. Everything looks green. Disks are ok etc. Status display on the front of the NAS seems normal.
So I turn to the logs. "No logs exist." Ehh? I try do download all logs anyway and it gives me some XML error message, which I guess is normal when no logs exist. I sure haven't deleted them.
So I try the memory test on the boot menu. No problems there. I also try the disk test on the boot menu. Finished fine and the NAS booted up again.
So I figure that the OS Reinstall on the boot menu should be able to solve this. Something is very corrupt/weird with how the NAS behaves! I think I managed to download a copy of the settings before I proceeded, since I wasn't sure what would actually be reset, and then I did the OS Reinstall.
The only thing that has changed is that the admin password is reset to standard - and I can't even change that. I fill in the fields and try to apply it. And, yes, nothing happens.
Then it struck me, maybe it's the browser (Chrome) or something?? So I tried IE as well, but no luck there. Also tried Safari in my phone.
I then tried getting SSH to work again by trying to upload that addon file, but I just got "Update file is not valid for this architecture" as error message.
So now I'm pretty much stuck here. I'm out of ideas! The NAS says everything is A-OK, but refuses to run anything I want to run on it and it doesn't tell me why. I can't even start rsync, which does not bode well either...
Please help! :(
Suddenly I noticed that CIFS was not behaving normally. I could browse shares, but not add any files.
This can of course be because of a million things, so I figured I try disabling and enabling that service in RAIDiator (4.2.27). So I disabled it and tried enabling it again, but selecting that service and clicking apply does absolutely nothing. The checkbox disappears and nothing more happens. No error message. Weird...? FTP still worked though, at least for browsing.
So I restarted the NAS. Then the CIFS service was still off and can't be started and the shares (naturally) disappeared from the network. Uh?! Not only that, but FTP had disabled itself. And, yeah, it won't start either. SSH had stopped working. Addons like Transmission as well won't start. I have Crashplan running on it, which I can't access either, so I don't really know if that starts or not.
Browsing via HTTPS still works, so the volume and the shares are still there. Everything looks green. Disks are ok etc. Status display on the front of the NAS seems normal.
So I turn to the logs. "No logs exist." Ehh? I try do download all logs anyway and it gives me some XML error message, which I guess is normal when no logs exist. I sure haven't deleted them.
So I try the memory test on the boot menu. No problems there. I also try the disk test on the boot menu. Finished fine and the NAS booted up again.
So I figure that the OS Reinstall on the boot menu should be able to solve this. Something is very corrupt/weird with how the NAS behaves! I think I managed to download a copy of the settings before I proceeded, since I wasn't sure what would actually be reset, and then I did the OS Reinstall.
The only thing that has changed is that the admin password is reset to standard - and I can't even change that. I fill in the fields and try to apply it. And, yes, nothing happens.
Then it struck me, maybe it's the browser (Chrome) or something?? So I tried IE as well, but no luck there. Also tried Safari in my phone.
I then tried getting SSH to work again by trying to upload that addon file, but I just got "Update file is not valid for this architecture" as error message.
So now I'm pretty much stuck here. I'm out of ideas! The NAS says everything is A-OK, but refuses to run anything I want to run on it and it doesn't tell me why. I can't even start rsync, which does not bode well either...
Please help! :(
47 Replies
Replies have been turned off for this discussion
- Either way. But at least if cache is not on the OS partition then the system won't lock up
Dewdman42 wrote:
Either way. But at least if cache is not on the OS partition then the system won't lock upTruthfully it would with the 4.4.1 upgrade issue. The files filling the OS partition are in /usr/local/crashplan/upgrade.
But I think that is a one-of bug, hopefully not a mistake they will repeat.
Thank you so much for your help!
The ReadyNas is now up and running.
First I deleted the upgrade-folders for crashplan.
Then I Moved the Crashplan folder to the datavolume and upgraded Java so that Crashplan could upgrade.
Hoping the Nas will stay running for a while :)
Best regards
Markus
- I had this problem a few months ago. After installing crash plan. Two culprits filled up the Os partition. One was /tmp dir was full of stuff. The other was due to a crash plan cache dir and since crash plan is located on /usr/local, that filled up the Os partition which is not very big. I solved my problem with ssh by emptying /tmp and by moving /usr/local/crashplan to /c/.crashplan and I put a sym link from /usr/local/crashplan to there. Problem gone, crashplan works great on my ultra ever since. At some point I also upgraded ram on ultra by replacing the simm with a bigger one, as crashplan is also a memory hog.
Dewdman42 wrote:
I had this problem a few months ago. After installing crash plan. Two culprits filled up the Os partition. One was /tmp dir was full of stuff. The other was due to a crash plan cache dir and since crash plan is located on /usr/local, that filled up the Os partition which is not very big. I solved my problem with ssh by emptying /tmp and by moving /usr/local/crashplan to /c/.crashplan and I put a sym link from /usr/local/crashplan to there. Problem gone, crashplan works great on my ultra ever since. At some point I also upgraded ram on ultra by replacing the simm with a bigger one, as crashplan is also a memory hog.FWIW this particular failure could eventually fill the data partition also - crashplan keeps redownloading the failed update over and over.
Everyone should move the cache (which can be done with a config change, and doesn't need a symlink). Mine is ~1.8 GB - IMO too much for the OS partition..
Moving everything to the c (or \data in the case of OS6) works as long as the RAID volume is healthy. I chose not to do that myself.
- Great info there!
I cant remember upgrading cralshplan on the Nas, but I definately think the OS partitin is full.
I didnt manage to find how to reach through via tech support mode before, almost seemed like some magical stuff absolutely only available to Netgear tech support but the guide you posted should make it for me I think ☺
Just have to find the telnet password, there was a video on youtube about tech support mode and a password flashed by in the video, have to test if that works.
Thank you so much for your time, will update wirh progress and perhaps some more questions 😉
Best regards
Markus - I already put extra memory in my readynas just for crash plan and that eliminated any problems of running out of memory. The root partition filling up is a separate issue
I upgraded my memory also.
The Crashplan cache is 1-2 GB so it will fill up the OS partition. But crashplan doesn't normally put stuff in \tmp.
crashplan doesn't directly, but java does, which is used to run crashplan. Java puts a tmp file of some kind into /tmp.
but as I said earlier there is supposedly a way to edit /usr/local/crashplan/run/run.conf and you can assign an alternate standard tmp file location to be used when crashplan is launched through java.
See this wki page about half way down under the section "waiting for backup"
https://wiki.archlinux.org/index.php/CrashPlan
But generally I think i agree, the big culprit here is the crashplan cache filling up the root partition very easily. Though when I was looking into this, my /tmp dir was full with 1.3GB worth of junk of some kind also, so I would like to understand more about how to keep my /tmp file empty or run some kind of cron job that will routinely clean it out, but I'm not sure how to do that safely.
- Yeah hope the memory upgrade works out alright for you! :)
Crashplan support just confirmed that the linux version only runs on 32 bit.InterClaw wrote: About 64-bit, that doesn't help us on our systems since Embedded Java only exists in 32-bit, right? :/ So until that changes there's no point in being able to allocate more than the ~3700MBs right?
Even with that restriction, the memory upgrade will still let me more than than double the 1536MB I was using before this issue started - which should keep me out of trouble for a while.- The restart logs are small - its not that they fill up the OS partition, just that they are a sign that the application decided it was very sick and restarted itself. I didn't see them on compacting, only backup attempts. It's good that you aren't seeing them.
I never saw the java files in /tmp. - Yeah, I tried compacting from one of the client computers so now I now what it should look like when it's doing the pruning and compacting. It seems like that doesn't start at the moment since it's busy backing up.
Yes, I did see those files when I had the problems earlier, but they were pretty small. The Java related files in /tmp were much larger. Since I increased the memory allocation I haven't had any more restarts.
Good command, thanks. :) - BTW, if you look in /usr/local/crashplan/bin, are you seeing a lot of restart*.log files? One of my main symptoms was seeing a new restart log file appear whenever crashplan tried to back up a file to the server. You'll also see these resets in the history log (either tail /usr/local/crashplan/log/history.log.0 or using the client's history page).
Also the files appeared to be backing up (very slowly) from the gui, but every time it restarted it tried to back them up again. And looking at backup_files.log.0 I could see a reported transfer rate of 0 bps.
"tail /usr/local/crashplan/log/backup_files.log.0 -n 250" gives you a pretty good picture of how things are going.
I believe it started with "synchronizing", then "compacting (deep)" and "pruning versions (deep)". There was a progress bar, with % completion. In my case it took a very long time (~10 days). I think it is a background task, and when it found stuff to backup it would switch over to the normal backup progress.InterClaw wrote: Yeah, the compact button does not seem to do anything at the moment. Did you get some sort of progress bar when you did this?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
