NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
roadfun
Aug 16, 2009Aspirant
Periodic (daily) Time Machine failures
I am running TM on an iMac with 10.5.8 to a Duo running 4.1.6. However I am getting a failure about once a day where TM pops up a dialog saying the network volume could not be mounted because of a problem with the username or password. It is very odd because it will do its hourly backup just fine for some period of time (a day or maybe a bit longer) before giving me this error. If I go to the TM Preferences I have to re-enter the username and password, then all is fine again for a day or so. This happened again just now and I snagged the Duo logs and also took a look at the Mac log. On there I see this series of possibly related messages:
Aug 16 17:07:40 Kobe kernel[0]: AFP_VFS afpfs_mount: /Volumes/ReadyNAS, pid 4993
Aug 16 17:07:40 Kobe Bonjour Mounter[267]: DiskAppearedCallback diskDescription = {\n DAVolumeKind = afpfs;\n DAVolumeMountable = 1;\n DAVolumeName = ReadyNAS;\n DAVolumeNetwork = 1;\n DAVolumePath = file://localhost/Volumes/ReadyNAS/;\n}
Aug 16 17:07:42 Kobe [0x0-0x14c14c].com.apple.systempreferences[4987]: chown: /Volumes/ReadyNAS/.001ec20ffc9e: Operation not permitted
Aug 16 17:07:43: --- last message repeated 1 time ---
Aug 16 17:07:43 Kobe kernel[0]: AFP_VFS afpfs_unmount: /Volumes/ReadyNAS, flags 0, pid 4998
Aug 16 17:07:43 Kobe Finder[161]: StatusMonitor::volumesChangedCallBack returned -47
Aug 16 17:07:43 Kobe kernel[0]: ASP_TCP do_thread_read: no reqInfo found for reqID 1
Aug 16 17:07:43 Kobe Bonjour Mounter[267]: DiskDisappearedCallback diskDescription = {\n DAVolumeKind = afpfs;\n DAVolumeMountable = 1;\n DAVolumeName = ReadyNAS;\n DAVolumeNetwork = 1;\n DAVolumePath = file://localhost/Volumes/ReadyNAS/;\n}
Aug 16 17:07:43 Kobe kernel[0]: ASP_TCP CancelOneRequest: cancelling slot 29 error 89 reqID 30 flags 0x9 afpCmd 0x14 so 0x7e7a330
In Duo afp.log
Aug 16 17:07:42 cnid_dbd[29190][logger.c:255]: I:Logger: doing log_setup, type 0, level 50, filename "/var/log/netatalk.log"
Aug 16 17:07:42 cnid_dbd[29190][logger.c:395]: D7:Logger: log_file_arr[0] now contains: {log_filename:/var/log/netatalk.log, log_file:(nil), log_level: 50}
Aug 16 17:07:42 cnid_dbd[29190][logger.c:398]: D5:Logger: log_setup[0] done
Aug 16 17:07:42 cnid_dbd[29190][main.c:210]: I:CNID: Setting uid/gid to 0/0
Aug 16 17:07:42 cnid_dbd[29190][main.c:309]: I:CNID: Startup, DB dir /c/.timemachine/.AppleDB
Any idea how I prevent this from happening? It means if I'm not in front of the Mac for awhile the TM backups stop.
Aug 16 17:07:40 Kobe kernel[0]: AFP_VFS afpfs_mount: /Volumes/ReadyNAS, pid 4993
Aug 16 17:07:40 Kobe Bonjour Mounter[267]: DiskAppearedCallback diskDescription = {\n DAVolumeKind = afpfs;\n DAVolumeMountable = 1;\n DAVolumeName = ReadyNAS;\n DAVolumeNetwork = 1;\n DAVolumePath = file://localhost/Volumes/ReadyNAS/;\n}
Aug 16 17:07:42 Kobe [0x0-0x14c14c].com.apple.systempreferences[4987]: chown: /Volumes/ReadyNAS/.001ec20ffc9e: Operation not permitted
Aug 16 17:07:43: --- last message repeated 1 time ---
Aug 16 17:07:43 Kobe kernel[0]: AFP_VFS afpfs_unmount: /Volumes/ReadyNAS, flags 0, pid 4998
Aug 16 17:07:43 Kobe Finder[161]: StatusMonitor::volumesChangedCallBack returned -47
Aug 16 17:07:43 Kobe kernel[0]: ASP_TCP do_thread_read: no reqInfo found for reqID 1
Aug 16 17:07:43 Kobe Bonjour Mounter[267]: DiskDisappearedCallback diskDescription = {\n DAVolumeKind = afpfs;\n DAVolumeMountable = 1;\n DAVolumeName = ReadyNAS;\n DAVolumeNetwork = 1;\n DAVolumePath = file://localhost/Volumes/ReadyNAS/;\n}
Aug 16 17:07:43 Kobe kernel[0]: ASP_TCP CancelOneRequest: cancelling slot 29 error 89 reqID 30 flags 0x9 afpCmd 0x14 so 0x7e7a330
In Duo afp.log
Aug 16 17:07:42 cnid_dbd[29190][logger.c:255]: I:Logger: doing log_setup, type 0, level 50, filename "/var/log/netatalk.log"
Aug 16 17:07:42 cnid_dbd[29190][logger.c:395]: D7:Logger: log_file_arr[0] now contains: {log_filename:/var/log/netatalk.log, log_file:(nil), log_level: 50}
Aug 16 17:07:42 cnid_dbd[29190][logger.c:398]: D5:Logger: log_setup[0] done
Aug 16 17:07:42 cnid_dbd[29190][main.c:210]: I:CNID: Setting uid/gid to 0/0
Aug 16 17:07:42 cnid_dbd[29190][main.c:309]: I:CNID: Startup, DB dir /c/.timemachine/.AppleDB
Any idea how I prevent this from happening? It means if I'm not in front of the Mac for awhile the TM backups stop.
82 Replies
Replies have been turned off for this discussion
- dmoffittAspirantI was having issues w/ TM failing but you're right, it had started and THEN failed, vs how you described it...
- rezonat0rAspirantIs it possible the periodic failures are related to this?
viewtopic.php?f=17&t=37714
The silence on this issue is deafening... :? - mdgm-ntgrNETGEAR Employee Retired
rezonat0r wrote: Is it possible the periodic failures are related to this?
viewtopic.php?f=17&t=37714
Yes, I guess it is quite possible.
Netatalk is what is used to give AFP functionality on the ReadyNas. Snow Leopard made some changes that affected backwards compatibility with devices using older versions of AFP. The latest Netatalk brings improved AFP compatibility (I think), so it should work much better. - rezonat0rAspirant
mdgm wrote: The latest Netatalk brings the version of AFP used in Snow Leopard (I think), so it should work much better.
True, but the periodic TM failures occur in exactly the same way under Leopard, not just Snow Leopard. So here's hoping the general TM fixes aren't just 10.6-specific. - mdgm-ntgrNETGEAR Employee RetiredI'm not sure if it does bring the newer AFP as I didn't see that mentioned anywhere (so I edited my post above), so it could still be AFP 3.1, but working better actually.
Here's some info I found on the netatalk version using RAIDiator 4.1.6
MDGM-NAS:~# afpd -V
afpd 2.0.3+cjk3 - Apple Filing Protocol (AFP) daemon of Netatalk
This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version. Please see the file COPYING for further information and details.
afpd has been compiled with support for these features:
AFP3.1 support: Yes
Transport layers: TCP/IP DDP
CNID backends: cdb dbd
SLP support: No
TCP wrappers support: No
Quota support: Yes
Admin group support: Yes
Valid shell checks: Yes
cracklib support: Yes
Dropbox kludge: No
Force volume uid/gid: Yes
afpd.conf: /etc/netatalk/afpd.conf
AppleVolumes.system: /etc/netatalk/AppleVolumes.system
AppleVolumes.default: /etc/netatalk/AppleVolumes.default
UAM search path: /usr/lib/netatalk/
Edit: it is still 3.1. I was wrong before. The next version of netatalk (currently in public beta) should bring 3.2. See http://netatalk.sourceforge.net/2.1/ReleaseNotes.html.
So 2.0.5 should be some improvement and later versions of netatalk will be even better. It's just a matter of waiting for the newer version to become stable and NetGear to test the newer version of netatalk to make sure it works properly with the ReadyNas. - rezonat0rAspirant
mdgm wrote: It's just a matter of waiting for the newer version to become stable and NetGear to test the newer version of netatalk to make sure it works properly with the ReadyNas.
That's what worries me :)
If Netgear can't even reproduce this obviously common problem... well... I get the sense that the NV's are collecting dust while they all use their shiny new Intel boxes. - mdgm-ntgrNETGEAR Employee Retired
rezonat0r wrote:
True, but the periodic TM failures occur in exactly the same way under Leopard, not just Snow Leopard. So here's hoping the general TM fixes aren't just 10.6-specific.
It shouldn't be just 10.6 specific, I think. If 2.0.5 doesn't improve things much, 2.1 which introduces AFP 3.2 should. - mdgm-ntgrNETGEAR Employee Retired
rezonat0r wrote:
If Netgear can't even reproduce this obviously common problem... well... I get the sense that the NV's are collecting dust while they all use their shiny new Intel boxes.
NetGear has introduced some fixes for x86 ReadyNas and should be able to compile similar fixes for the older Sparc ReadyNas (if necessary). NetGear is working on 4.1.7, which is expected to be released sometime soon (hopefully).
NetGear can try and do workarounds etc. to limit problems, but if netatalk lacks some features, there's only so much NetGear can do without a newer version of netatalk. - rezonat0rAspirantUnderstood, I would simply like Netgear to ack the problem in the first place.
I'm really happy that the Infrant team seems to be mostly intact since the buyout, but my experiences since then have been less than stellar. Infrant-era customers were left out of a 5-year warranty, screwed by defective power supplies that should have been recalled (but weren't), and now have problems with advertised features and get virtually no feedback.
Sour grapes? Maybe. Off-topic? I don't think so. I would like a reason to recommend the ReadyNAS (as a Netgear product) to others, because right now I'm very much on the fence. - mdgm-ntgrNETGEAR Employee Retired
rezonat0r wrote:
Infrant-era customers were left out of a 5-year warranty
When you purchased the product there was no 5-year warranty. You can't expect NetGear to provide a warranty longer than what you purchased. They will honour an extended Infrant warranty if you purchased one. If your NAS is out of warranty, that doesn't mean they'll ignore your posts. They can't replace your NAS chassis, but they can give some help to fix some problems.rezonat0r wrote:
screwed by defective power supplies that should have been recalled (but weren't)
If your serial number falls in the range depending on your region you may qualify for a free replacement PSU (if you haven't got it already).rezonat0r wrote:
and now have problems with advertised features and get virtually no feedback.
Time machine is working for me on my main NV+ (Sparc ReadyNas) using Leopard. I haven't tried it with Snow Leopard yet. I run my Time Machine jobs manually, so I don't know about the cause of the periodic (daily) Time Machine failures. Our Jedi friends have limited time and if they responded to everything they would be slower to fix problems due to less time to spend on that. After all there's only 24 hours in a day.rezonat0r wrote:
Sour grapes? Maybe. Off-topic? I don't think so. I would like a reason to recommend the ReadyNAS (as a Netgear product) to others, because right now I'm very much on the fence.
These forums are great, new business ReadyNas come with 5-year warranties. Sure there have been some issues, and there always is going to be some with any Linux box used as a NAS with Windows and Mac machines, but as problems arise they are typically fixed over time.
Related Content
- Oct 20, 2020Retired_Member
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!