SD changes disk permissions?

[cweger]

Hi,

Yesterday I ran SuperDuper for the first time on a new MacPro running 10.5.2. I was backing up a 500GB volume used solely for Final Cut render storage.

After the clone ran (successfully), I dismounted the backup drive, and launched Final Cut. Final Cut immediately complained that my scratch volume was not writable.

A Get Info on the volume showed something curious: even though in the list of users at the bottom of Get Info it listed my permissions as Read/Write, the text right above the user list said "You can read only." ???

Sounds to me like some kind of ACL-related issue. Anyway, the only way I could fix it was to mark the volume as "Ignore Ownership."

So, I'm wondering what happened? Nobody touched the computer or that volume between the time SuperDuper ran and this permissions issue, and I had successfully been running Final Cut earlier in the day.

Any ideas?

[dnanian]

We don't change permissions, but we do ensure ownership is on. If you need to have full write permission on the drive, keep ownership on, but change the permissions for the volume.

[Michael@wengam]

I have one internal drive for my System and User home folders, and another drive (actually partition on the same drive) that contains files I want to share between all users of this machine--for this data drive, I check 'Ignore permissions on this volume' in its Get Info window.

I keep finding that 'Ignore permissions on this volume' has been unset by some process: not me or another user, for certain. I do make a clone of this partition every night using SuperDuper! -- will that unset 'ignore permissions'?

[dnanian]

Yes. As above, set permissions for the drive and user groups appropriately, rather than turning permissions off.

[Michael@wengam]

I'm afraid that will just give me the same problems I have had trying to share files by keeping them in the Users-->Shared folder. I never seemed to be able to set file or folder permissions so that either of the two users of this machine could open, edit and save a shared file without changing its name, etc.

I tried, and failed, to understand and set ACLs to share files my way.

I'd get it working, then after some time I would find that documents could not be opened by the 'wrong' user, or could not be edited and saved under the original file name. It may be OK to have to change the name of a Word draft after every user's edit, but not OK (for me) to be forced to change the name for a 1GB Photoshop file that has been worked on, generating multiple huge files every time a different user does something to it.

In frustration, I resorted to putting shared files on a separate volume with 'ignore permissions on this volume' checked. That seems to give just the kind of file sharing I want, at least until the box gets itself unchecked.

Am I missing something here? Are there liberal permissions I can set on a non-boot volume that will let me share files as I would like and will 'stick' as settings?

[dnanian]

You set a file and folder inherted ACL that set your permissions to read/write for all, Michael?

[Michael@wengam]

I have just tried to set that, it seems to work. But I feel like I have been here before, in the case of applying these ACLs to the Shared folder, only to find it start to give problems at some point in future.

I opened a program called Sandbox (not to be confused with SD!'s 'Sandbox' volume), where I enabled ACLs for the volume, set the most liberal permissions I could find (for 'everyone') and then propagated them to enclosed items using a Sandbox menu command. For now, either user seems to be able to open, edit and save documents under the original file name.

Actually, if this really does work, I would just as soon go back to having a single volume containing all my documents as well as the 'boot' System, Library, Users etc.

[dnanian]

That's the idea of inherited ACLs, so I'm glad it's working.

[Michael@wengam]

Originally Posted by dnanian

That's the idea of inherited ACLs, so I'm glad it's working.

OK, I am going back to sharing files in the Shared folder, but with ACLs set so both users can read and write files.

Anyone who is contemplating sharing files by putting them on a non-boot volume and setting 'ignore ownership' should be aware that SuperDuper! will uncheck this setting when it clones your drive.

Also, there is a useful tip for setting up the ACLs you need recently posted here:
http://www.macosxhints.com/article.p...90219133314985

[dnanian]

And -- really -- anyone who's contemplating this should use ACLs. Bypassing OSX's security/ownership setup with the 'ignore' checkbox is something that just shouldn't be done except in very exceptional cases.

[Michael@wengam]

Now I remember why I was driven to trying the 'ignore' checkbox: because Photoshop (at least CS3) seems to ignore ACLs. If a user2 opens a Photoshop document saved by user1, then tries 'Save', they'll get a message saying the file is locked and cannot be saved, even when the ACLs are set as they should be for this kind of sharing.

The problem is well documented. Here is a good recent discussion:
http://discussions.apple.com/thread....sageID=9551280

Well documented, but no-one seems to have a solution, other than dragging files to your desktop before editing them, which enforces the ACLs.

[dnanian]

Sounds like something that should be reported to and fixed by Adobe...

[Michael@wengam]

According to that Apple Discussions thread above, Adobe considers this the proper behavior and actually recommends the 'drag copy to desktop' workaround as the correct workflow for users collaborating on Photoshop documents. You can certainly find users' discussions of this 'problem' going back many years.

[dnanian]

That's not really what I read there: it seems that Photoshop isn't properly handling ACLs and has provided a workaround, not that it's "proper behavior".

Note that you could adjust your umask to deal with this, too.