Ignore Ownership / Lock Hassles

Question

Level 1

23 points

Ignore Ownership / Lock Hassles

Two of five external drives are experiencing "Ignore Ownership Of This Volume" issues. On one, used only for a SuperDuper main HD backup, suddenly has lost its Ignore Ownership status and the lock to open & change this is grayed out. This prevents backups from happening.

Another, used always as the primary scratch disk for Photoshop, resets its Ignore Ownership status every time the computer goes off/on.

Two other drives have their Ignore Ownership locks grayed out, so the status there can't be changed, but at least the Ig-Own stays checked.

Once Ig-Own has been checked, any unlocked condition can not be re-locked, on any drive, internal or external. No amount of standard remedies from Disk Utilities, DiskWarrior 4 or Info window settings helps.

None of the other Ig-Own threads I've seen here seem to parallel this exactly, and it's driving me nuts. Any way to set these directly?

g5 dual 2.5, Mac OS X (10.5.4)

Posted on Sep 15, 2008 8:00 AM

Reply

Answer 1

Sep 15, 2008 8:17 AM in response to Peter Inova1

I experienced very similar issues with 4 of my seven drives and found it was a permissions issue.

I received the help below and it cured my problems, I hope it works for you.

Run the following commands in terminal

sudo chflags nouchg /Volumes/"drive-name"

sudo chmod 775 /Volumes/"drive-name"

Put the name of the external instead of "drive-name" in the above. keep the quotes. you'll have to enter your admin password (which you won't see). that's normal. repeat for every affected drive.

Reply

Answer 2

Peter Inova1 Author

Level 1

23 points

Sep 15, 2008 9:28 AM in response to main.street

Thanks for the note. I tried this with my dysfunctional backup volume and after going through it twice I don't see anything different in the Info listing for the drive. The lock is still grayed out and the Ignore Ownership checkbox is still not accessible.

Do you need to restart the computer after making a change like this?

Reply

Answer 3

Peter Inova1 Author

Level 1

23 points

Sep 16, 2008 9:13 AM in response to main.street

After a few extra minutes, the sudo commands eventually took hold. That did the trick, but only as long as the computer stayed awake. On restart the drives went right back into their impaired state.

It must be something deeper and stronger than Unix.

Is it possible to set the flags that are causing these conditions from a higher level function in OS X?

Reply

Answer 4

Sep 16, 2008 2:33 PM in response to Peter Inova1

It must be something deeper and stronger than Unix.

I don't think so.

private/var/db/volinfo.database controls enabling and disabling permissions on a local mount.

Possible issues:

A corrupt volinfo.database.

A volume whose owner is unknown to Open Directory.

For starters, post the output from the following command:

cat /private/var/db/volinfo.database

Reply

Answer 5

Peter Inova1 Author

Level 1

23 points

Sep 19, 2008 5:11 PM in response to Mark Jalbert

Here's what that obtained:

A30F6DCF8E1ABCF7: 00000001
DCFF4A1B8D12B909: 00000001
A34914CCB55638BD: 00000001
3BFFEB11A7D3F6E9: 00000000
9C8D41C1F94B6AF2: 00000001
50692952DE778AB2: 00000001
4C9D94D3F9C724B0: 00000001
3F8D2CB0CA7B3E37: 00000001
5473C75951202740: 00000000
D3D24B57117608D2: 00000001
AC584AE8025B7A6F: 00000001
1D584B4778F23339: 00000001

...all of which is glork to me.

(and of course I was kidding about the "stronger than Unix" quip...)

-iNova

Message was edited by: Peter Inova1

Reply

Answer 6

Sep 23, 2008 2:05 PM in response to Peter Inova1

Well, Let me explain the "glork". The first column of letters and numbers represent a hard drive or hard drive partition. The second column is the binary representation of whether a "disk" is set to ignore or respect permissions. The 1 at the end of the second column means the drive is permissions enabled. Your volinfo.database looks OK.

Post the output from the command:

/bin/ls -aOle /Volumes

Then the output from the command:

sudo /bin/ls -aOle /Volumes

Reply

Answer 7

Peter Inova1 Author

Level 1

23 points

Sep 23, 2008 2:25 PM in response to Mark Jalbert

I appreciate the advanced peek into the guts of my mac...

Here's the first output:

drwxrwxrwt@ 10 root admin hidden 340 Sep 23 10:35 .
drwxrwxr-t 103 root admin - 3570 Jun 14 2006 ..
drwxrwxr-t@ 78 root admin - 2720 Sep 16 09:52 1T
drwxrwxr-t@ 84 root admin - 2924 Sep 16 09:52 400G
drwxr-xr-x 31 peterinova staff - 1122 Sep 14 18:22 863G
drwxr-xr-x 21 peterinova staff - 782 Jun 10 00:23 BU eBook
drwxrwxr-t 96 root admin - 3332 Sep 16 11:40 HDBU
drwx------ 16 peterinova staff - 500 Sep 17 15:24 LC1TB
lrwxr-xr-x 1 root admin - 1 Sep 23 05:30 Mac HD -> /
drwxr-xr-x 34 peterinova staff - 1224 Sep 22 10:55 Max157

Here's the second

drwxrwxrwt@ 10 root admin hidden 340 Sep 23 10:35 .
drwxrwxr-t 103 root admin - 3570 Jun 14 2006 ..
drwxrwxr-t@ 78 root admin - 2720 Sep 16 09:52 1T
drwxrwxr-t@ 84 root admin - 2924 Sep 16 09:52 400G
drwxr-xr-x 31 _unknown _unknown - 1122 Sep 14 18:22 863G
drwxr-xr-x 21 _unknown _unknown - 782 Jun 10 00:23 BU eBook
drwxrwxr-t 96 root admin - 3332 Sep 16 11:40 HDBU
drwx------ 16 peterinova staff - 500 Sep 17 15:24 LC1TB
lrwxr-xr-x 1 root admin - 1 Sep 23 05:30 Mac HD -> /
drwxr-xr-x 34 _unknown _unknown - 1224 Sep 22 10:55 Max157

I hope this clears things up. There are ongoing problems with Time Machine that seem to have appeared with the 10.5.5 update as well. It's dead for all intents and purposes.

Regards,

-iNova

Reply

Answer 8

Oct 13, 2008 5:18 AM in response to Peter Inova1

Hi Peter,

Three drives- 1T, 400G, and HDBU have the sticky bit set in their file mode. This would suggest to me that these drives contain valid operating systems (installed or clones). These drives should NOT be set to ignore permissions. I do not use SuperDuper nor TimeMachine but I believe both pieces of software would require a drive to be permissions enabled.

Drive LC1TB is owned by you, peterinova and the file mode excludes anybody but you from accessing the drive.

Three drives- 863G, BU eBook, and Max157 are owned by the magic unknown user. I'm not certain why you set them up this way but any user accessing these drives would "think" that they were the owner. When a file or folder is owned by the magic unknown user the file appears to be owned by the user accessing it. Two of these drives are listed in the volinfo.database to ignore permission.

There is a command line utility vsdbutil that will operate on the volinfo.database.

vsdbutil -h
Usage: vsdbutil [-a path] | [-c path ] [-d path] [-i]
where
-a adopts (activates) on-disk permissions on the specified path,
-c checks the status of the permissions usage on the specified path
-d disowns (deactivates) the on-disk permissions on the specified path
-i initializes the permissions database to include all mounted HFS/HFS+ volumes

First check the drives in question like this:

sudo vsdbutil -c /Volumes/BU\ eBook

To set this drive to ignore permisson then:

sudo vsdbutil -d /Volumes/BU\ eBook

Reply