NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
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
- This is getting OT, but I'll bite. :D
mdgm wrote: 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.
Of course, but it would have been a gesture of goodwill, seeing as how it's the same exact hardware. The move did not go unnoticed.mdgm wrote:
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).
Sorry, but this wasn't the way it worked at the time. And I was there.
The protocol was to follow the normal support channels after your PSU died. In other words, Netgear said: "Your unit has a known defective PSU. Please wait until the PSU starts emitting smoke and exposes all of your hard drives to god-knows-what before contacting support."
Oh, and don't forget the fan-reversal service action. That was a good one. :rofl:mdgm wrote:
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.
So you aren't really using Time Machine as designed. That's fine, but the point is that normal, hourly incremental backups are not 100% working as advertised. I guarantee that you would encounter the same issues as we do if you let Time Machine run normally, regardless of OS version.mdgm wrote: 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.
This thread was started Sun Aug 16, 2009. Still no official acknowledgment of the problem. I'll let others draw their own conclusions from this fact. rezonat0r wrote: Of course, but it would have been a gesture of goodwill, seeing as how it's the same exact hardware. The move did not go unnoticed.
I remember reading that the price of the product went up when NetGear took over. Everything has its price. If you want a five year warranty you can move your drives to a new NV+ or 1100.rezonat0r wrote:
Sorry, but this wasn't the way it worked at the time. And I was there.
The protocol was to follow the normal support channels after your PSU died. In other words, Netgear said: "Your unit has a known defective PSU. Please wait until the PSU starts emitting smoke and exposes all of your hard drives to god-knows-what before contacting support."
Oh, and don't forget the fan-reversal service action. That was a good one. :rofl:
You're right. But if you followed the Service Action that should have reduced the likelihood of the PSU failing. Products can have problems. There wasn't a need to replace the PSU unless it failed. They may have recalled the defective products after discovering the problem, but they can't help it if resellers didn't return it or the product had already been sold.rezonat0r wrote: the point is that normal, hourly incremental backups are not 100% working as advertised. I guarantee that you would encounter the same issues as we do if you let Time Machine run normally, regardless of OS version.
Ok. Well, hopefully Netatalk 2.0.5 fixes it. We can hope.mdgm wrote:
This thread was started Sun Aug 16, 2009. Still no official acknowledgment of the problem. I'll let others draw their own conclusions from this fact.
I agree that official acknowledgement would be nice.mdgm wrote: I remember reading that the price of the product went up when NetGear took over. Everything has its price. If you want a five year warranty you can move your drives to a new NV+ or 1100.
To be clear, the price went up because Netgear discontinued the disk-less versions after they acquired Infrant.mdgm wrote: I agree that official acknowledgement would be nice.
:D- Hi,
after playing a lot with different ways of connecting Macs (and PCs) to ReadyNas-Shares i found that some of the problems that occured where caused by the Macs keychain.
Since i haven't encountered the error in question, i thought it might be helpful to post my keychain-entries (Snow Leopard).
The ReadyNas is used in a mixed environment so i chose to use CIFS and the ReadyNas IP-address to connect to the shares (like this: cifs://10.0.0.1/software).
This creates an entry in the 'Log-In' keychain with the name 10.0.0.1 and the following settings:
(yes, it says smb instead of cifs :wink: )
Using the Time Machine feature left me with another entry, this one in the 'System' keychain, being called A.local (A being the host-name to the IP-adress 10.0.0.1) with the following settings:
(AFP on this ReadyNas is only used for Time Machine, so it is not advertised over Bonjour or Appletalk and the AFP-permissions for each share are disabled, with no user- or groupentries. The box for 'extended AFP rights' (? - mine says 'erweiterte Einstellungen'...) is also unchecked.)
In case anyone is interested, i also stumbled upon a difference in Time Machine behaviour between Leopard and Snow Leopard:
I used to have one backup (and i mean really one backup = one date) created by a MacBook Pro under Leopard.
The name of the Sparsebundle was its device name followed by an underslash and the MAC-address of the ethernet-adapter used to connect to the ReadyNas.
When starting Time Machine (the program, not the backup) on the MBP the mounted volume had a similar name as the sparsebundle. I was able to backup to the same sparsebundle using that MBP, but this time with Snow Leopard.
Then i backed up a mac mini for the first time to the same ReadyNas but directly with Snow Leopard and the volume was mounted with the name 'Time Machine-Backups' and the created sparsebundle was named after the minis device name.
I therefore deleted the MBPs strangely named sparsebundle and did a complete new backup now also directly with Snow Leopard. This time the volume and sparsebundle were named in the like of the ones from the mini.
Maybe someone can find some of this useful...
- Johannes. mdgm wrote: rezonat0r wrote:
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.
That's not how things work, if a company ships a product they are obligated to fix it within warranty regardless of what the issue is, they can't just blame it on a hardware or software supplier. You're saying that because an opensource product is used in a commerical product (and not a cheap one) the company can sit back and say "not our fault" ? No no, they have to fix it, it's not the customers fault that they chose netatalk, or whichever other product it could have been opensource or not, it's also not netatalk's problem, it's entirely opensource, you can use it or not and on your own risk, and "own risk" that's NetGear/Infrant here. If you buy a new car and it rusts within a year, the dealership or factory can't tell you that it's because they bought bad paint and you should take it up with the paint supplier, or wait a year and maybe we'll have a solution for you.
I'm certain NetGear are doing all or well something to fix a lot of the bugs, but it's imho not quite good enough, in particular as they sold the ReadyNAS 1100 as being meant for business use.. yeah right.lasseoe wrote: mdgm wrote:
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.
You're saying that because an opensource product is used in a commerical product (and not a cheap one) the company can sit back and say "not our fault" ?
Actually, Netgear has not said anything. That's the problem :D- So wrapping all this up (from 5 pages), I'm left with the following conclusions:
- The periodic failures are not fatal, do not cause any lasting problems, and will (almost?) always correct themselves the next go-around when Time Machine kicks off another backup an hour later.
- There is no conclusion as to what is causing them for sure.
- There are fixes that Netgear is working on, to be included with the 4.1.7 (Sparc) release that may or may not address this issue.
That said, anyone know how far along they are with releasing 4.1.7? Searching the forum, I heard that it was "in beta" in March, and should be out very soon..
I'd love to see if 4.1.7 (with support for the latest AFP 3.3 features, thinking we can finally ditch the warnings in the log about TM Lock Stealing and Server Reply Cache as well) resolves this issue.
Thoughts?
\marc - Guys-
My last back up with time machine was April 15, and -every- backup attempt from any of my three Macs simply fails for the beforementioned reasons.
This is a serious problem that needs to be addressed.
Yes, I'm seeing the error posted in the Mac logs, and yes, I'm seeing unrecoverable TCP errors in the ReadyNAS logs.
Presently the combination of a NetGear ReadyNAS+ and Macs is simply not working altogether, so either NetGear retracts support for Macs and refunds all those involved, or fixes the problem ASAP.
peter. pb10006 wrote:
My last back up with time machine was April 15, and -every- backup attempt from any of my three Macs simply fails for the beforementioned reasons.
You are responding to a thread that has been dead for over 1 year, has 5 pages of responses and there has been at least 1 firmware update made for every ReadyNAS product since the last comment. Maybe you could be more explicit, even open your own thread, rather than expect people to go through all that info to figure what your issue might be?Yes, I'm seeing the error posted in the Mac logs, and yes, I'm seeing unrecoverable TCP errors in the ReadyNAS logs.
TCP errors would suggest networking problems.Presently the combination of a NetGear ReadyNAS+ and Macs is simply not working altogether, so either NetGear retracts support for Macs and refunds all those involved, or fixes the problem ASAP.
You have a problem so all Mac users should be refunded? Seriously?
I appreciate your comments may be borne of frustration, but if you really want to solve this - please create a topic with full details of the problem you are having, your setup, software/firmware/OS versions etc and what you have already tried to fix the problem. Then you may get a more informative & helpful response- Sorry, but the last post to this thread was April 12 - and on March 20 it was noted that NetGear has not addressed this problem.
I have not been able to make an appropriate back up since April 15 w/o changing any of my infrastructure - now it may be that the amount of data to back up has exploded and we run into networking issues at that point, but directly connecting any of my macs to the ReadNAS NV+ directly does not help. My Mac and ReadNAS NV++ complain with the following errors:
AFP_VFS afpfs_mount: /Volumes/ReadyNAS, pid 39489
AFP_VFS afpfs_unmount: /Volumes/ReadyNAS, flags 0, pid 40133
ASP_TCP do_thread_read: no reqInfo found for reqID 1
ASP_TCP CancelOneRequest: cancelling slot 30 error 89 reqID 52135 flags 0x9 afpCmd 0x14 so 0x1aed983c
0_gmac_disconnect: 0
0_gmac_rcverror: 0
0_gmac_autonegotiation: 0
0_gmac_link_fail: 0
0_gmac_idleerror: 0
0_gmac_vlan_tags: 0
0_gmac_bad_packet: 540
tcp_retransmit: 6377
tcp_retransmit_unrecovered: 852
My ReadyNAS NV+ runs the latest firmware (at least: the box tells me that there has not been an update since then).
As for posting - the problems are exactly as the ones described in this thread.
Please correct me if I missed anything in this thread.
all the best,
peter.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
