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
- I don't think you zipped the config back up correctly.
When the config is extracted from the zip file it will be extracted to a folder called e.g. "_READYNAS_CONFIG" (name of the folder will be longer using NAS name and timestamp but for convenience we'll used this name)
In order for the config to be restored to the correct location you need to highlight the contents of the _READYNAS_CONFIG folder (e.g. the etc folder) and create a zip archive from that. If you create a zip archive of _READYNAS_CONFIG and then restore it via Frontview it will be restored to /_READYNAS_CONFIG/etc/default/netatalk rather than /etc/default/netatalk - Mdgm, thanks for the thought, but I am positive the zip was correct. I may not have explained it on this thread clearly, but the zip going back to the NAS was the same as it came from it, but only the netatalk file had different contents. I suspect the reason the new zip didn't take is probably the same reason the OS Reinstall didn't help.
However, good news. I said to heck with it and installed the Root SSH add on. Then I renamed the file (mv /etc/default/netatalk /etc/default/netatalk.original), then did an OS Reinstall via the boot menu, and hurray, the netatalk file NOW looks correct (included below). Time Machine is now plugging away happily. I was able to mount my Media share via AFP too. However, I am still at 10.6.8 and just got the message "Message from server "netgear" Something wrong with the volume's CNID DB, using temporary CNID DB instead. Check server messages for details. Switching to read-only mode."
Oh boy, this is fun! Does it get better? :-(
I will go searching the forum for this next problem.netgear:/etc/default# cat netatalk
# Appletalk configuration
# Change this to increase the maximum number of clients that can connect:
AFPD_MAX_CLIENTS=50
# Change this to set the machine's atalk name and zone.
# NOTE: if your zone has spaces in it, you're better off specifying
# it in afpd.conf
#ATALK_ZONE=@zone
ATALK_NAME=`awk -F. '{ print $1 }' /proc/sys/kernel/hostname`
# specify this if you don't want guest, clrtxt, and dhx
# available options: uams_guest.so, uams_clrtxt.so, uams_dhx.so,
# uams_randnum.so
AFPD_UAMLIST="-U uams_dhx.so,uams_dhx2.so,uams_guest.so"
# Change this to set the id of the guest user
AFPD_GUEST=nobody
# Set which daemons to run (papd is dependent upon atalkd):
ATALKD_RUN=yes
PAPD_RUN=no
AFPD_RUN=yes
TIMELORD_RUN=no
CNID_METAD_RUN=yes
# Control whether the daemons are started in the background
ATALK_BGROUND=yes - mikefort: Good to hear that other issue is fixed.. We are looking into the CNIDB database issue right now. Give it a hour and trying accessing the share again. It could take sometime for the database to get updated.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
