NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Failing Readynas Ultra 6
Hi, I have an old Readynas ultra 6 running the old 4.2.x firmware, which is starting to fail. I'd like to know if I can salvage it. It has 4 disks in a raid configuration, runs OS 4.2.x, with s...
Do you have ssh enabled on the Ultra?
Do the shares still show up in Frontview?
I'm wondering if the OS partition is filling.
Well, I am getting there.
Once I starrted the raid service and mounted the OS filesystem, but before I did the binds and chroot, the output of df is
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 10240 0 10240 0% /dev
/dev/md0 4184756 4162260 0 100% /sysroot
So, I am at 100% usage of the OS file system, which presumably explains why my box doesn't work. I tried the bind and chroot suggested by stephenb, but has a bit of trouble due to my limited familiarity with linux (running df from the chroot shell indicated no filesystems; maybe this is is what it should say, but for now I'm just using the basic tech support mode shell, and not giving the bind and chroot commands).
Now I have to find what's taking up so much space. The tivo databases seem to live in
/sysroot/var/lib/readytivo
This takes up only about 2,900 blocks in the du output, so it is probably not the culprit.
The log directory /sysroot/var/log is only about 71,000 blocks, so that is probably not the problem.
The thing that catches my eye are the USB directories. I use USB drives for backup. The first part of the output of the ls command is
drwxr-xr-x 2 4096 Mar 12 2008 USB
drwxr-xr-x 3 4096 Dec 1 05:05 USB_HDD_1_1
lrwxrwxrwx 1 16 Dec 16 2016 USB_HDD_3_2 -> /USB/USB_HDD_3_2
lrwxrwxrwx 1 16 Dec 16 2016 USB_HDD_3_3 -> /USB/USB_HDD_3_3
The first line USB directory is empty, which is what I would expect in tech support mode. The 3rd and 4th lines, USB_HDD_3_2 and USB_HDD_3_3 are therefore links presently pointing to nothing; again this is likely appropriate for tech support mode.
But the second line, USB_HDD_1_1 is a real directory, which, according to du, is 3478624 blocks. It contains one directory, fileserver, which is the name of one of my shares which I do backup to external harddrives.
Could something have gone wrong, such that the system backed-up my "fileserver" share to the OS partition, rather than an external drive? Perhaps the external drive could have disconnected during the backup job; this is actually something I have observed, not infrequently. Usually I just reconnect the backup drive the next morning, and think nothing of it.
If this is what happened, then
cd /sysroot
rm -fr USB_HDD_1_1
should fix my problem.
There have been others that have reported that a mounting issue with a USB drive caused data to actually be written to the root directory instead of a mountpoint there pointing to the drive. It sounds like that's your issue. Note that there could be files there that you think are on your USB drive, but aren't. So take a look at them before you delete them.
Thanks very much to those who responded, especially StephenB, who correctly diagnosed my problem and provided me witth the technical details to solve it. For the record, in case anyone else has the same issue:
Problem: My ReadyNas Ultra 6+ is backed up to external disk drives, and to a newer Readynas 316. A few weeks ago, it suddently failed in a peculiar manner. It would not serve shares to client computers. Frontview worked, but was broken: it showed no logs on the log page, no shares on the share page, it would not allow me to install add-ons such as the SSH toggle.
The diagnosis: StephenB nailed it - my OS partition was at 100%, and thus full
The Solution: confirm the diagnosis by accessing the system through tech support mode; to get to tech support mode follow the instructions in the Readynas Harware Manual, and then telnet to the Readynas; I used putty on a Windows PC. You have to log in with user root and PW infr8ntdebug (this password is easy to find in this forum and on the internet, so I see no harm in posting it here).
You then have to start the raid service (type the command start_raid.sh) , and mount the OS file system (mount /dev/md0 /sysroot); the device may be different on other Readynas systems.
Tech Support mode provides a Linux shell with limited commands; earlier in this thread StephenB describes how to use mount --bind and chroot to invoke the OS system itself, which has access to more commands. I did not find this necessary, the tech support mode shell was all I needed.
I was able to confirm StephenB's diagnosis with the df command, which showed my OS partittion at 100% usage. I then had to use variations of ls and du to find the culprit; the Linux find command may be useful, though I didn't use it. Helps to know a bit of Linux (I know a bit, but I'm far from a guru myself)
In my case, the problem was a directory tree under /sysroot called USB_HDD_1_1 This directory tree should not have been there; it should have been a link to an external drive; instead the OS partition contained part of a backup of one of my shares. The backup should have been saved on an external USB drive, but something went wrong and it was saved in the OS partition, thereby filling it up, and causing my system to fail. Most likely my USB drive disconnected due to a hardware glitch while my backup job was running. I deleted the directory tree using the command line with the appropriate rm command, rebooted, and all seems well.
One other note: there is an option in the Readynas boot menu to "reinstall OS." This will not fix the problem; this option will reinstall the OS, but it doesn't remove errant files, and won't clear out an over-full OS partition. StephenB points this out earlier in the thread. To fix the problem, you need to use tech support mode, telnet, and know the basics of linux commands.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
