NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Ultra 4: Getting off on the wrong foot
Using RAID 5. Access method is AFP. Using Snow Leopard 10.6.8, but might have updated from 10.6.7 through all the activity. Started life with firmware 4.2.15.
As concise as I can put it:
• Installation was easy, filled up volume 40% with data.
• Regular weekly scan reported disk 2 failed.
• Replaced disk with same model, resync was quick.
• Regular weekly scan reported disk 2 failed.
• Replaced disk with same model, resync was quick.
• Regular weekly scan reported disk 2 failed.
• Replaced disk with same model, resync was quick.
• I suspected at first that disk 2 was having the issues because of heat (hottest slot by 2 degrees) but temps were very normal range.
• On each failed disk, I wiped the data on a PC and there were no S.M.A.R.T errors nor accessibility errors.
• I poked around the logs are it appeared the weekly scanning hit a bug and wrongly concluded the disk failed. Clearly there were no issues with the disks themselves. I do embedded FreeBSD for my career, so I am not lightly suggesting this.
• Regularly weekly scan reported disk 2 failed.
• Rebooted the Ultra without a scan on start and it found the disk was good and resynced it quick.
• Next weekly scan did not find a failed disk.
• Noticed that the Ultra was automatically installing the updates that I thought it was ONLY downloading.
• I thought I was in the clear, but...
• Some major disk activity resulted in the mount dropping. Frontview reported disk 1 (yes, disk 1) failed.
• Disk would not come back with rebooting with or without a scan.
• In non-redundant mode, I was unable to access my shares through either AFP or SMB. More precisely, on one attempt to access via SMB, I got in but didn't have permissions to go to any shares except home directory. After logging out, could never connect via SMB again.
•I updated to 4.2.18, reinstalled the OS, reentered the admin password, and still no luck on AFP/SMB connections. I did some experimentation with trying to connect and observing what the logs show, esp afp.log.
The afp log says:
[startup]
Jul 22 12:16:19.906310 afpd[2737] {status.c:707} (I:AFPDaemon): "netgear"'s signature is 03E1...9ACF
Jul 22 12:16:19.906987 afpd[2737] {afp_config.c:372} (N:AFPDaemon): AFP/TCP started, advertising 192.168.1.61:548 (2.2-rc1)
Jul 22 12:16:30.091376 afpd[2737] {auth.c:148} (I:AFPDaemon): uam: "No User Authent" available
Jul 22 12:16:30.091470 afpd[2737] {auth.c:148} (I:AFPDaemon): uam: "DHX2" available
Jul 22 12:16:30.091513 afpd[2737] {auth.c:148} (I:AFPDaemon): uam: "DHCAST128" available
[attempted login]
Jul 22 12:17:00.529703 afpd[3130] {dsi_tcp.c:212} (I:DSI): AFP/TCP session from 172.28.15.8:60588
Jul 22 12:17:00.531937 afpd[2737] {main.c:185} (I:AFPDaemon): child[3130]: done
Jul 22 12:17:04.379595 afpd[3134] {dsi_tcp.c:212} (I:DSI): AFP/TCP session from 172.28.15.8:60589
Jul 22 12:17:04.379739 afpd[3134] {dsi_getsess.c:85} (I:DSI): dsi_getsess: too many connections
Jul 22 12:17:04.380824 afpd[2737] {main.c:183} (I:AFPDaemon): child[3134]: exited 1
Concerns:
Did I start using the Ultra around the time of a bad batch of firmware updates?
I am not a hacker and followed the instructions very strictly.
I am still in the warranty period, this is way too needy of a product so far and want to believe it is easier than this.
Case number is 16052871.
As concise as I can put it:
• Installation was easy, filled up volume 40% with data.
• Regular weekly scan reported disk 2 failed.
• Replaced disk with same model, resync was quick.
• Regular weekly scan reported disk 2 failed.
• Replaced disk with same model, resync was quick.
• Regular weekly scan reported disk 2 failed.
• Replaced disk with same model, resync was quick.
• I suspected at first that disk 2 was having the issues because of heat (hottest slot by 2 degrees) but temps were very normal range.
• On each failed disk, I wiped the data on a PC and there were no S.M.A.R.T errors nor accessibility errors.
• I poked around the logs are it appeared the weekly scanning hit a bug and wrongly concluded the disk failed. Clearly there were no issues with the disks themselves. I do embedded FreeBSD for my career, so I am not lightly suggesting this.
• Regularly weekly scan reported disk 2 failed.
• Rebooted the Ultra without a scan on start and it found the disk was good and resynced it quick.
• Next weekly scan did not find a failed disk.
• Noticed that the Ultra was automatically installing the updates that I thought it was ONLY downloading.
• I thought I was in the clear, but...
• Some major disk activity resulted in the mount dropping. Frontview reported disk 1 (yes, disk 1) failed.
• Disk would not come back with rebooting with or without a scan.
• In non-redundant mode, I was unable to access my shares through either AFP or SMB. More precisely, on one attempt to access via SMB, I got in but didn't have permissions to go to any shares except home directory. After logging out, could never connect via SMB again.
•I updated to 4.2.18, reinstalled the OS, reentered the admin password, and still no luck on AFP/SMB connections. I did some experimentation with trying to connect and observing what the logs show, esp afp.log.
The afp log says:
[startup]
Jul 22 12:16:19.906310 afpd[2737] {status.c:707} (I:AFPDaemon): "netgear"'s signature is 03E1...9ACF
Jul 22 12:16:19.906987 afpd[2737] {afp_config.c:372} (N:AFPDaemon): AFP/TCP started, advertising 192.168.1.61:548 (2.2-rc1)
Jul 22 12:16:30.091376 afpd[2737] {auth.c:148} (I:AFPDaemon): uam: "No User Authent" available
Jul 22 12:16:30.091470 afpd[2737] {auth.c:148} (I:AFPDaemon): uam: "DHX2" available
Jul 22 12:16:30.091513 afpd[2737] {auth.c:148} (I:AFPDaemon): uam: "DHCAST128" available
[attempted login]
Jul 22 12:17:00.529703 afpd[3130] {dsi_tcp.c:212} (I:DSI): AFP/TCP session from 172.28.15.8:60588
Jul 22 12:17:00.531937 afpd[2737] {main.c:185} (I:AFPDaemon): child[3130]: done
Jul 22 12:17:04.379595 afpd[3134] {dsi_tcp.c:212} (I:DSI): AFP/TCP session from 172.28.15.8:60589
Jul 22 12:17:04.379739 afpd[3134] {dsi_getsess.c:85} (I:DSI): dsi_getsess: too many connections
Jul 22 12:17:04.380824 afpd[2737] {main.c:183} (I:AFPDaemon): child[3134]: exited 1
Concerns:
Did I start using the Ultra around the time of a bad batch of firmware updates?
I am not a hacker and followed the instructions very strictly.
I am still in the warranty period, this is way too needy of a product so far and want to believe it is easier than this.
Case number is 16052871.
13 Replies
Replies have been turned off for this discussion
- Can you send in your logs so I can take a look at them.
- Email was sent.
- I looked into your logs
Can you do a os reinstall that should fix the /etc/default/netatalk it will also do a fscheck.
Then we can go from there. - I had done the OS reinstall since the firmware was updated.
The trick I learned was that from the boot menu the option is selected with the paper clip reset button, not the power button like I was doing at first. :)
Is there something in the logs to make sure I did it correctly? - A firmware reinstall will usually fix a file issue.
Can you run another file system check.
When you replaced the possible bad disk did you replace with the same disk after checking it or a new disk?
With all these issues with the drive it almost sounds like a hardware issue with the NAS. - I did the firmware update the same way again to be sure. I watched the "Booting... Updating FW" on the display, and then "Booting...". I was unable to mount AFP still.
Next, I enabled a "volume scan" on reboot, then rebooted. I assume that is what you meant by a file system check. No luck after that either.
I re-downloaded the Frontview -> System -> Config Backup -> Backup and complete logs and the error is the same and the netatalk still has my DNS information in it. Is it possible that netatalk is not getting cleaned up in the OS Reinstall???
When you are asking about what disk I used as the replacement, you are going back in history a little bit. At first, when the ReadyNAS said disk 2 failed, I shut down cleanly, then immediately replaced the disk with a new disk right out of the box. I did that a couple times assuming the disk did actually fail. You see that with new drives from time to time. However statistical improbability quickly suggested it wasn't the disk.
The last time disk 2 "failed", I did the reboot WITHOUT scan, and it treated the disk like it was new and synced that, then I never saw issues again. If I had to ship another disk back to the dealer, the NAS was going with it. :-(
All the logs I saw in Frontview -> Status -> Logs suggested to me it was just a software error.
I really don't think it is a hardware issue, I think it is software. I hope I had a bad firmware or 2 causing the "disk failures" and hope I am now past that, but this pesky AFP and SMB share issue is getting in the way.
[UPDATE] SMB mounting seems to work now. I am almost tempted to modify the Configuration backup to correct Netatalk myself, and restore. :-) - I tried a little experiment to try to get AFP to work. Time Machine has been down for about a week and I am getting antsy to install Lion! :-)
1. Frontview -> System -> Config Backup -> Backup, selected just 'Services' and downloaded it.
2. Unzipped zip file.
3. Renamed zip file to .zip.original
4. In the unzipped folder, in /etc/default/netatalk, I replaced the file with:# Set defaults. Please change these options in /etc/default/netatalk.
AFPD_UAMLIST="-U uams_dhx.so,uams_clrtxt.so,uams_randnum.so"
AFPD_GUEST=nobody
AFPD_MAX_CLIENTS=50
ATALK_ZONE=
ATALK_NAME=`/bin/hostname --short`
ATALK_BGROUND=no
# Read in netatalk configuration.
if [ -f /etc/default/netatalk ]; then
. /etc/default/netatalk
fi
5. Re-zipped the folder, noted that the name was the same as when I downloadeded it originally.
6. Frontview -> System -> Config Backup -> Restore
7. Rebooted NAS
8. Tested AFP, no joy :-(
9. Frontview -> System -> Config Backup -> Backup, selected just 'Services' and downloaded it.
10. Unzipped and examined /etc/default/netatalk. Contents were still DNS information. So either the restore doesn't restore this file, or it did, and some other process overwrote it.
Chewbacca, what process will restore/replace the netatalk file in question? - Chewbacca, what process will restore/replace the netatalk file in question?
- Delete the netalk file it should create a new one.
- Thanks, but how do I do that with Frontview?
I only have Frontview and will not enable SSH root access due to the warning unless Level 3 advises it. :-)
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
