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
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.
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?
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?
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.
