Jump to content

Local disk access and sharing changes after Retrospect duplicate runs


Recommended Posts

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

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

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

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

> 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

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

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

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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...