NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
hanging
4 Topics
4.2.31 on my Ultra 6 has killed my NAS? Drive is read only and frontview hangs.
So I logged into my Ultra 6 and noticed there was a firmware upgrade available from May 2017! Since I get at least two emails from my NAS every day I assume it should have emailed me about this, but anyway, that's a minor problem. I installed the upgrade and then.... time machine no longer worked. My two laptop macs no longer could log in. I rebooted the ReadyNAS (since sometimes it gets in a mode where nothing can log into it) and it didn't help. Probing a little further, I attempted to change the Time Machine access password to be sure I had it correct. The web interface hung! A hard reset and disk check later and some errors were corrected. All SMART reading good and no errors. So I tried again. Same result. Every time I tried to change the time machine access password the UI and effectively the ReadyNAS hung. The next step was re-installing the OS, using the reset hole and front panel buttons. I did this. Another disk check. Now I can attempt to change the time machine access password and it appears to work, except the "volume size" of the time machine space is set back to the default 3000 every time I apply changes. Digging deeper, it appears my partitions are mounted read-only which would explain a lot. # touch /c/doc/SymformContrib/delete_this touch: cannot touch `/c/doc/SymformContrib/delete_this': Read-only file system During boot in kern.log I have this EXT4-fs error (device dm-0): ext4_mb_generate_buddy:726: group 10 blocks in bitmap, 32768 in gd Sep 14 10:59:30 sleepy kernel: Aborting journal on device dm-0-8. Sep 14 10:59:30 sleepy kernel: EXT4-fs (dm-0): Remounting filesystem read-only Sep 14 10:59:30 sleepy kernel: EXT4-fs error (device dm-0) in ext4_reserve_inode_write:5602: Journal has aborted Sep 14 10:59:30 sleepy kernel: EXT4-fs error (device dm-0) in ext4_reserve_inode_write:5602: Journal has aborted Sep 14 10:59:30 sleepy kernel: EXT4-fs error (device dm-0) in ext4_ext_remove_space:2437: Journal has aborted Sep 14 10:59:30 sleepy kernel: EXT4-fs error (device dm-0) in ext4_reserve_inode_write:5602: Journal has aborted Sep 14 10:59:30 sleepy kernel: EXT4-fs error (device dm-0) in ext4_orphan_del:2098: Journal has aborted Sep 14 10:59:31 sleepy kernel: EXT4-fs error (device dm-0) in ext4_reserve_inode_write:5602: Journal has aborted The first line seems to be some Linux bug which may have been fixed. My data is there. The filesystem is read only. This seems to be showing up other bugs (such as the entire device hanging). Does anyone have any suggestions beyond "Backup your 12GB data, install OS6 and start again"? Many thanks in advance.1.1KViews0likes5Comments
Rsync, hanging, OS 6,
I have a couple of old Sparc Duos that I am wanting to transfer the data to my new(to me) RN104. One of them has 0.2TB, the other 1.8TB data. I have previously transferred about 80% of the data from the 1.8TB Duo to the RN104 I have set up Rsync backup job on the RN104. It has been running for 60 hours now and is still "in progress". There are two issues: 1. Only one folder has not been replicated in full, and there have been no files copied for over 24 hours now. 2. The folder timestamps are showing the date copied, not the date on the original folder structure There is no log of the backup job visible, is there any way to discover what the RN104 is actually doing. I am thinking I should cancel the job, and either rerun it, or simply create a new job to run against the folder that hasn't been fully copied yet, but thought it would be sensible to ask for advice before I press the big red button. I have made a previous posting about the folder timestamps, but didn't get the issue fully sorted. I am forming the opinion that OS 6 is much more about presentation that actual data handling as my Rsync jobs on the Sparc boxes always copied over the folder last modified dates faithfully Thanks in advance for any help ps, RN104 is running 6.6.0, the Duo is running 4.1.133.9KViews0likes9CommentsRsync perfomance / hanging
I have a couple of old Sparc Duos that I am wanting to transfer the data to my new(to me) RN104. One of them has 0.2TB, the other 1.8TB data. I have previously transferred about 80% of the data from the 1.8TB Duo to the RN104 I have set up Rsync backup job on the RN104. It has been running for 60 hours now and is still "in progress". There are two issues: 1. Only one folder has not been replicated in full, and there have been no files copied for over 24 hours now. 2. The folder timestamps are showing the date copied, not the date on the original folder structure There is no log of the backup job visible, is there any way to discover what the RN104 is actually doing. I am thinking I should cancel the job, and either rerun it, or simply create a new job to run against the folder that hasn't been fully copied yet, but thought it would be sensible to ask for advice before I press the big red button. I have made a previous posting about the folder timestamps, but didn't get the issue fully sorted. I am forming the opinion that OS 6 is much more about presentation that actual data handling as my Rsync jobs on the Sparc boxes always copied over the folder last modified dates faithfully Thanks in advance for any help ps, RN104 is running 6.6.0, the Duo is running 4.1.132.3KViews0likes1Comment
ReadyNAS 104 system hanging frequently after 6.4.0 upgrade
Hi All, I have a pretty new ReadyNAS 104 system (August, 2015). Currently populated with 3 x 4TB WD RED drives, and a single Segate 3TB drive (to be upgraded once funds allow). Since upgrading to FW 6.4.0 I have found that the system will hang whenever a maintenance process is performed - Scub, Balance or Defrag, which I had scheduled previously. I have now disabled all the schedules and left the system alone, but overnight it has hung again, after approximately 72 hours of normal operation. It responds to pings, but the GUI will not load, it has dropped off the network via all protocols, fails to allow you to SSH into it and pressing the power button (Once, twice and three times) has absolutely no effect. The only option is to pull the plug. Also, after every hang, forcing a power pull, the system starts a complete resync of the volume, which always starts at 25.10% and takes about 4 days to complete over the 15TB of raw storage. Obviously this is putting undue strain on the disks everytime it is happening. Happy to provide logs to any friendly Netgear Admins, and any advice from any of you lovely people would be gratefully received. Cheers, Tipster10KViews2likes26Comments