baybeacon Posted June 28, 2006 Report Share Posted June 28, 2006 I am running Retrospect 6.1.126 on a Mac Dual 2.3 Ghz G5 operating OS X Server 10.4.6. Among other things I use this server to run duplicates of a local internal hard drive, as well as networked client hard drives, to external Firewire backup hard drives that are local to this server. After duplication scripts run, the ownership and sharing attributes of these local external backup hard drives mysteriously change. Before the scripts run, the disks are shared, with certain users and groups having read/write privileges. After the scripts run, the read/write privileges are mysteriously reset to "none", the owner is changed to "root", and the group is changed to "wheel." Sometimes the "share this item and its contents" box is mysteriously unchecked as well. Manually resetting the attributes back to the desired state does not prevent the problem from recurring. What's going on and how can I avoid this continual reset of sharing and ownership attributes? Link to comment Share on other sites More sharing options...
nekr0phage Posted June 28, 2006 Report Share Posted June 28, 2006 Hi, Are you duplicating directly to these drives or into folders on the drives? Link to comment Share on other sites More sharing options...
baybeacon Posted June 28, 2006 Author Report Share Posted June 28, 2006 I am duplicating to folders or subfolders on those drives. Maybe a dozen different client hard drives, plus one local hard drive, per external drive. Thanks for your interest! Link to comment Share on other sites More sharing options...
nekr0phage Posted June 28, 2006 Report Share Posted June 28, 2006 Kent, Does this happen every time any duplicate is run? Or does it happen with any particular scripts that you can tell? What if you go into the options for your duplicate scripts and diable the option to duplicate ACL's? Link to comment Share on other sites More sharing options...
CallMeDave Posted June 28, 2006 Report Share Posted June 28, 2006 Quote: After duplication scripts run, the ownership and sharing attributes of these local external backup hard drives mysteriously change Could you describe what you're doing using Retrospect's terminology of "Source" and "Destination" please? It's just not clear (or not easy to discern) exactly what you're doing, or what you're seeing when you do it. Dave Link to comment Share on other sites More sharing options...
baybeacon Posted June 29, 2006 Author Report Share Posted June 29, 2006 Thanks Foster and Dave for you questions. Foster: I run a number of scripts automatically throughout the day, so I have not noticed any correlation. I will try disabling some scripts and see if I can pin down any offenders. I will also look into the ACL angle. Dave: The backup sources are not affected by this problem. Affected are two independent external drives containing the destination folders. These two exernal drives containing the destination folders are connected via Firewire to the backup server running OS X Server 10.4. The backup server internal hard drive also happens to be the source of one of the backup scripts. All but one of the other dozen or so backup sources are networked clients running OS 9 and client version 5.1.157. One of the client sources is running OS X. All of the backups are duplication scripts. Sorry some of this wasn't clear in my initial post. Thanks for your interest! Link to comment Share on other sites More sharing options...
baybeacon Posted June 29, 2006 Author Report Share Posted June 29, 2006 Further response to Foster: At your suggestion I have now disabled the ACL duplication option in both of the OS X duplication scripts. However, neither of the source volumes had ACLs enabled. I'll let you know if that works. Thank you. Link to comment Share on other sites More sharing options...
baybeacon Posted July 6, 2006 Author Report Share Posted July 6, 2006 Further info: Disabling the ACL duplication option does NOT do the trick. Duplicating a remote client to a folder still changes the sharing and/or access status of the entire destination drive. The problem does not seem to occur when duplicating a local OS X source volume, only when duplicating a client OS 9 or OS 8 source volume. My only alternative at this point is to continue running OS 9 volume client backups with an OS 9 version of Retrospect, a slow and inefficient process. Does anyone have any other ideas? Link to comment Share on other sites More sharing options...
CallMeDave Posted July 6, 2006 Report Share Posted July 6, 2006 > All but one of the other dozen or so backup sources are networked clients running OS 9 and >client version 5.1.157. One of the client sources is running OS X. > The problem does not seem to occur when duplicating a local OS X source volume, only when >duplicating a client OS 9 or OS 8 source volume. I think this revelation is pretty important, that you only observe the issue with Classic Mac clients. I vaguely recall a report of something like this quite a while ago, and I thought that there was a response from a Dantz person that it had been addressed (but I have been unable to locate the post here on the Forum). But it seems as if it'd be quite easy to test, for someone having a Classic Mac client and an external HD. I'd also be curious if the same thing happens with Retrospect running on a non-server version of OS X, and/or if the same thing happens to drives that have no share points configured with Workgroup Manager. I'd suggest opening up a support incident with EMCInsignia. If they can reproduce it, and it turns out to be a software defect, you can request a refund (and probably get it). If it's not a bug but they can help you solve the problem, it's surly worth the $75 or so. Dave Link to comment Share on other sites More sharing options...
rhwalker Posted July 6, 2006 Report Share Posted July 6, 2006 This just might be related to the fact that Mac OS X 10.4.6 (and .7) interpret the protection bits differently than before, because Retrospect tries to make everything "right". We saw a related problem when our Xserve G5 updated from 10.4.4 Server to 10.4.6 Server, when some old shares brought forward from a now-retired ASIP server got strange behavior. See this Apple KB article: Apple KB article 303882 Caused a bit of head scratching until we figured it out, only clue was it was only for shares brought forward from ASIP. The way to see is to use Terminal to do an ls -lo of the problematic volume, see if any uchg flags are set. Dantz might have fixed it, and then Apple may have broken it again when they changed the interpretation of some bits that were used in the past, unused in early 10.x, and then magically became used or interpreted differently as of 10.4.6. You might be seeing a different manifestation of this same issue. Russ Link to comment Share on other sites More sharing options...
CallMeDave Posted July 7, 2006 Report Share Posted July 7, 2006 Immutable items can certainly cause headaches with Retrospect, such as the inability to delete an item that's been matched in advance of a Duplicate. But this sounds different. We already know that the Source needs to be a Classic Mac OS client. Learning if the problem shows up with any (external drive based) Destination, or just with server managed Destination Volumes, will be very helpful. Steps to reproduce (as guessed from the thread) Mac OS X Server 10.4.6 Retrospect 6.1.126 Mac OS 9 client running Retrospect Client control panel External FireWire drive with active shares for the Server (FooDrive) Source=OS 9 client Destination=Defined subvolume on external FireWire drive - Note permissions on /Volumes/FooDrive/ - Note permissions on /Volumes/FooDrive/SubvolumeFoo/ - Run Duplicate, Replace entire disk - Note permission changes (if any) on /Volumes/FooDrive/ - Note permission changes (if any) on /Volumes/FooDrive/SubvolumeFoo/ Link to comment Share on other sites More sharing options...
rhwalker Posted July 7, 2006 Report Share Posted July 7, 2006 Yep, those are the steps that I inferred, too. But I really think it might be due to Retrospect restoring a bunch of permission bits that it thinks mean one thing (from OS 9) or were previously ignored by OS X that Apple has now decided have different meanings and are no longer ignored by OS X as of 10.4.6 Server. That's what happens when you change the interpretation of old bits. I suggest that the Retrospect support summer interns give this a shot as their summer project. In all fairness, though, I think that the issue ought to be tested using the current Mac OS 9 (Classic) Retrospect client, which is 5.1.180 (May 4, 2006). There are two minor issues with this client in that it can't be pushed out over the network by Retrospect (no .rcu file exists, only a Stuffit archive that has to be manually installed on each client) and that, once installed, it doesn't report its version number (missing resource), which will cause support issues. Now I think that the 5.1.180 client update was only to plug a security hole if you had a hacker with access to your LAN, and I don't think that anything else was changed, but the issue ought to be tested on the current version of Retrospect Classic client. The link is here: Retrospect 5.1.180 Classic client Russ Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.