NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Admin page unavailable after cancelled backup job & hard reboot, shares are working
Hopefully someone can help me get out of this deadlock. I recently added a rsync backup job to sync the local /media share with an USB drive that was connected via the rear USB socket of the RN...
Did you at any point disconnect or power down the USB drive before the backup job said it was done? I ask because I suspect that it continued after that. But once the USB drive wasn't connected, it began to copy files to the mount point in the OS partion instead of the USB drive that should have been mounted there. That'll fill the OS partition in a hurry.
The message you are seeing is the location where the OS crashed, undoubtedly due to the too-full OS partition. If you are now able to enable SSH after the OS re-install, you need to go in and clear out any files that were copied to the mount point directory.
The fact that your files were copied to media/media is the way the rsync backup jobs are designed. I disagree that's the way it shoud be, but it is. The work-around is that you need to go back into the backup job configuration after it's created and put a single forward slash "/" as the source path.
Did you at any point disconnect or power down the USB drive before the backup job said it was done? I ask because I suspect that it continued after that. But once the USB drive wasn't connected, it began to copy files to the mount point in the OS partion instead of the USB drive that should have been mounted there. That'll fill the OS partition in a hurry.
The message you are seeing is the location where the OS crashed, undoubtedly due to the too-full OS partition. If you are now able to enable SSH after the OS re-install, you need to go in and clear out any files that were copied to the mount point directory.
The fact that your files were copied to media/media is the way the rsync backup jobs are designed. I disagree that's the way it shoud be, but it is. The work-around is that you need to go back into the backup job configuration after it's created and put a single forward slash "/" as the source path.
Sandshark wrote:Did you at any point disconnect or power down the USB drive before the backup job said it was done? I ask because I suspect that it continued after that. But once the USB drive wasn't connected, it began to copy files to the mount point in the OS partion instead of the USB drive that should have been mounted there. That'll fill the OS partition in a hurry.
OMG. That is absolutely possible. rsync backup jobs on the RN214 always were a mystery to me, however still being the only choice to have a one-click incremental nobrainer backup to an attached USB3 device excluding btrfs snapshots and a couple of other unnecessary directories. Once I got aware of the /media/media problem, I wanted to avoid 4TB of redundant data being copied only to be deleted once the job was finished. Hence I canceled the job and did not really care about the HDD access LED in the NAS. I then probably have ejected the USB device (don't really remember if I did) or it could be that at that point the admin page was already unresponsive.
Since I was stupid enough not to enable SSH and the power button shutdown did not work, I had to pull the plug. Later I learned about RAIDar, which I could have tried to force a shutdown as well.
After the forced restart, the admin GUI just showed the progress bar similar to https://kb.netgear.com/26883/ReadyNAS-OS-6-Admin-Page-is-offline, no way around that. I resorted to the OS reinstall boot menu option after which I could log onto the admin GUI successfully. Then I saw the "Volume: System volume root's usage is 99%. This condition should not occur under normal conditions. Contact technical support." log message but sure enough, I don't have any technical support contract.
So the master plan was to enable SSH shell access for admin, which failed (blocked GUI again and all other kinds of weird behaviour). After a couple of OS reinstalls, suddently a "firmware image unpack failure" (or likewise) was displayed on the LCD panel and the admin GUI came up completely non-localized, with just the message tokens/placeholders instead of the real messages. Still no SSH access.
That was the moment when I called it a day and performed a complete factory default reset, knowing that I had at least backed up all the data (without the snapshots unfortunately, since the NTFS partition on the external USB drive does not support them). Currently, the device is resyncing its data (at ~10%).
Sandshark wrote:The message you are seeing is the location where the OS crashed, undoubtedly due to the too-full OS partition. If you are now able to enable SSH after the OS re-install, you need to go in and clear out any files that were copied to the mount point directory.
That was the plan. But it seems that my iterations and an OS partition filled up to the brim was not allowing this configuration change. Lesson learned. Enabling SSH was the veryfirst thing I did after the RN214 came up in it's pristine state.
Sandshark wrote:The fact that your files were copied to media/media is the way the rsync backup jobs are designed. I disagree that's the way it should be, but it is. The work-around is that you need to go back into the backup job configuration after it's created and put a single forward slash "/" as the source path.
Usually I'm aware of those rsync subtleties but that's what happens, if you're copying files while working on other stuff in parallel...
The big question is now: If I run an rsync backup job in the future and find out that things are going haywire: What is the recommended way of cancelling them in a safe way so that this disaster can't happen again? Does it suffice to wait for the job shown as "Cancelled"? Is there a logfile to have a look at?
That was quite a miserable day to say the least. Nevertheless many thanks for your explanations, I learned a lot about rsync again.
For future aborts, I recommend you check the log (available inn the backup job menu) to see that it says the job was cancelled. The log is only updated at completion (it doesn't show progress), so that should be a sure way to know it's done.
There are other ways we could have helped you clean out the system, but it's complicated. Since you had a full backup, that's really the road of least resistance in this kind of case.
Sandshark wrote:For future aborts, I recommend you check the log (available inn the backup job menu) to see that it says the job was cancelled. The log is only updated at completion (it doesn't show progress), so that should be a sure way to know it's done.
There are other ways we could have helped you clean out the system, but it's complicated. Since you had a full backup, that's really the road of least resistance in this kind of case.
One last thing and on a sidenote:
What would be the recommended way to restore my backup? NB: It's around 4TB of data on an external USB3 box with NTFS filesystem. I could abuse the "Backup" GUI option (kind of backwards rsync, *sigh*), just a trivial copy-paste in the NAS' file browser (will this also copy hidden/system files - at least they are not shown there?) or probably even by rsyncing in an SSH root shell, e. g. something like:
su rsync -avh /media/USB_HDD_1/home/ /data/home &
to restore the home folders (don't know if activating checksums with -c is really necessary). At least eton had success doing it that way (see his post in https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/How-to-restore-a-nas-with-rsync/td-p/840685, I modified directories to match my RN214). I would somehow need to send the command to the background, since I don't want to keep the SSH console window open for hours. Dragging the files around the network connection with a remote PC would be the very last resort.
Thanks again!
Addendum: Just sending rsync to the background with "&" does not work. The process will stop once the SSH terminal window is closed. Some people had success with nohup, redirecting stdin, stdout and stderr to /dev/nul. This seems quite complicated to me.
Then there is the fraction recommending to install the screen package with
apt-get update apt-get install screen
and then
screen -S rsync rsync -avh /media/USB_HDD_1/home/ /data/home
in your SSH terminal to create a screen named "rsync", start the restore and hit CTRL+a, d to detach the screen. Once the restore is finished, you would run
screen -r rsync
in the SSH terminal to reconnect.
I would probably send stdout and stderr to a file, so there is a way of diagnosing things in case something went wrong:
rsync -avh /media/USB_HDD_1/home/ /data/home >~/rsync.log 2>&1
What do you think? I'm a bit hesitant though to install $STUFF on my RN214 box - if that works at all...
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
