I back up both an iMac and a Macbook Pro to the same archive. The iMac backup is done from an account named "merna" and the MBP from and account named "ralph." The backup disk is mounted on the iMac, and the MBP backs up over the network. For the last week or so, maybe since I installed beta 59, I've been having a problem where iMac backups fail due to a permissions problem at the end of the backup. For example:

Action 2012-02-28 13:00:54 Failure Failed
Action 2012-02-28 13:00:54 cannot open file
Action 2012-02-28 13:00:54 Minutia OSErr: -5000
Action 2012-02-28 13:00:54 Error: Insufficient access privileges for operation
Action 2012-02-28 13:00:54 Minutia OSErrName: afpAccessDenied
Action 2012-02-28 13:00:54 Minutia Path: /Volumes/SpareB/userbackupB.quanta/hash_adjunct.index
Action 2012-02-28 13:00:54 Permissions: 0x0003

The problem file in question is owned by ralph, with read-only permission for everyone else, while all the other files in the qrecall bundle are owned by merna. It looks to me like each time a backup is run the ownership of the files changes to the account name that ran that backup, and that process is now choking for some reason. It often chokes on the hash_adjunct.index file, but sometimes on others as well.

I've been running this setup since I started using qrecall in 2007 or thereabouts, and the problem is a new one, so I assume the recent version does something different in the way it handles permissions.

Ralph

Ralph Strauch wrote:The iMac backup is done from an account named "merna" and the MBP from and account named "ralph."

That is most likely the problem. A QRecall archive is a document, and is subject to all the regular document ownership and permission rules. That is, you typically have write access to documents you create, but not documents created by another user.

When the MacBook Pro captures, it should log into the iMac as "merna" not "ralph". That way, the archive essentially belongs to "merna" and is updated as "merna" both on the iMac and from the MacBook Pro.

I've been running this setup since I started using qrecall in 2007 or thereabouts, and the problem is a new one, so I assume the recent version does something different in the way it handles permissions.

The handling of files in the archive bundle hasn't changed significantly in years.

I suspect that either MacBook Pro is currently logged into the iMac as "ralph" when the capture starts, or the alias and/or keychain of the MacBook Pro has recently decided that the default log-in for the iMac's volume should use the "ralph" account. Either way, when the MacBook Pro writes files remotely on the iMac, it's doing so as "ralph" which changes the ownership of the archive files.

If you think the MacBook Pro is auto-logging in as "ralph" instead of "merna", you can delete the saved password for "ralph" from the keychain (in the Passwords section, find the "network password" kind of entry for the iMac that has an "afp://..." location, and just delete it). Now disconnect from the server and manually start the capture action. When QRecall tries to auto-mount the remove volume, it will either go back to using the other saved account/password, or will prompt you for a log in. Log in as "merna" and click the "save on keychain" option.

An alternative is to capture to separate archives, and then the ownership won't collide.

James Bucanek wrote:

Ralph Strauch wrote:The iMac backup is done from an account named "merna" and the MBP from and account named "ralph."

That is most likely the problem. A QRecall archive is a document, and is subject to all the regular document ownership and permission rules. That is, you typically have write access to documents you create, but not documents created by another user.

When the MacBook Pro captures, it should log into the iMac as "merna" not "ralph". That way, the archive essentially belongs to "merna" and is updated as "merna" both on the iMac and from the MacBook Pro.

This didn't feel right to me. I've been backing up using a different user account on each machine for five years and haven't had this problem until this month. As I thought more about it, I remembered that OSX has an "ignore ownership on this volume" option under GetInfo for external drives that was usually checked on by default. I looked at the drive I was having problems with, and sure enough, that option was unchecked. With the option checked, everything on the disk shows up as belonging to the active account -- to ralph on the MBP and to merna on the iMac. With it unchecked, the ownership can apparently become mixed, and that's what created my problem. Re-enabling it seems to have solved it. The question still remains, of course, of why the option became unchecked suddenly after all these years? I'll keep monitoring it, and see if it happens again. It may have had something to do with the 10.7.3 update.

One other note. The errors which occurred when "ignore ownership . . ." was disabled did corrupt the archive and require a repair.

Ralph

Ralph,

You're absolutely correct. The "ignore ownership" option completely slipped my mind.

So for the record, setting the "ignore ownership and permissions" option on the volume is the third way of avoiding ownership collisions between multiple systems.

The ignore ownership option is not a property of the volume. It is actually remembered in a database that's stored in the startup OS. If you do anything that might reset that database (like a clean install of the OS), or do something to the volume so that its UUID changes (like reformatting it), then the OS forgets that it was ignoring ownership on that volume and the setting reverts to its default, which is to NOT ignore ownership and permissions.