Permissions nightmare with Leopard (10.5)

[qubex]

Hello. I've been reading these forums for a long time but this is the first time I post because I'm experiencing a really vexing problem with Mac OS 10.5 ("Leopard").

First of all: I have the slightly unusual setup of having two seperate hard drives, one mounted at / for my "main" (system, apps, etc.) filesystem and one mounted at /Users for my data files. My user account's home directory (/Users/james) is here. This has never caused any problems but the upshot is that I can't use Disk Utility's Repair Permissions function to fix this problem, assuming it would work, which it probably wouldn't. (I have tried to use Leopard's installer Repair ACLs function in Repair Password Utility and it hasn't done any good.)

Whenever I move files to the trash, or try to save, I'm either told that the files are locked or up pops the usual dialog box asking me for an administrator password. In the present condition, the machine is almost unusable.

I have the following problem with my permissions: I don't practically have ownership of the folders inside my home directory. The permissions tell me I have, full dwrx yada yada yada, but actually I don't. If I try to apply read/write privileges to all enclosed items, Finder trawls through something, but nothing happens.

Same for sudo chmod and sudo chown invoked with the -R flag.

The very interesting thing is this: if I inspect the individual files' permissions with Get Info, I discover I have read/write privileges, there's an unknown user with Read Only, and Everybody appears twice, both with Read Only. If I try to add or remove a user in the permissions box, Finder crashes. If, however, I reaffirm one of the Everybody's Read Only privileges, I suddenly regain full control of my file.

This is not a simple problem and I don't have a clue how it occurred. How do I remove this spurious Everybody from the permissions? Alternatively, how do I resolve whatever ambiguity is going on to cause Everybody to appear twice? Is the unknown user the root of the problem? Is there a way to annihilate the current (obviously corrupted) ACLs and start from scratch?

I look forward to hearing what you suggest. Thanks in advance.

[hayne]

If you have an unusual setup (e.g. /Users on a different drive) then I wouldn't trust Finder's Get Info about the permissions. Instead you should look at the permissions using commands in Terminal. See this Unix FAQ (http://forums.macosxhints.com/showthread.php?t=40648) for instructions.
New with Leopard is the use of ACLs. When you do 'ls -l' on a file or folder in Leopard, a + at the end of the permissions tells you that there are ACLs active on that file or folder.
Use the "-e" option to 'ls' to see the ACLs.

[qubex]

I had ACLs active on my System drive but not on my Users drive.

In the end I went completely mad, copied all the contents of my home directory over to a blank partition, nuked the drive, recreated my user account, re-imported everything, and now it works.

Hardly elegant, but at least it worked.

[shiatis]

This is *exactly* the problem I have had after going to 10.5. Most files on my drive, no matter where they live, show the "everybody" user twice (with two different settings). This prevents me from doing just about anything to any of those files without putting in a password. The only way I could get RP to run from disk util was to log on as root, create a new temp user, transfer the contents of my user directory into the temp user's, delete my user, create a new user with the same info as the one I deleted and transfer all my dirs back from temp. After that, running RP took just over 27 hours to complete and gave the "ACL found but not expected" message on just about every file on my hard drive. Do a search on that string and you'll find loads of other people having the same problems. It seems that ACLs are getting applied to thousands of files that they shouldn't be applied to during install.

Also of note: after the upgrade my user icon reverted to an older icon that I hadn't used in months and a second user I had set up for my wife some time back disappeared from the accounts list, but her home folder was still there.

[lockley]

I moved my entire home folder to a external FW drive, installed CLEAN leopard with format included and then moved my files back to a new admin account with the same name i used in tiger... result?

most folders in my home directory ask me for a password for EVERYTHING, some apps crash on quit because preference files can't be written...

I don't know unix, so, the question is:

Is there a MACOSX APP or simple terminal command i can use to fix this?

PD: Ive tried almos every combination of privilege settings with no solution, most files/folders say "account(me) - read & write" but i have to put my password to do anything...

thanks in advance

[Cy-Winnipeg]

I have had the same problem with permissions and having the "everybody" user twice.

The solution to the everybody user being twice is easy. Run the Terminal application and for your user directory and files in it, remove the permission to outside world users.

The following command solved it for me:

chmod -R o-rwx username
chmod -R g-rwx username

This got rid of both the "unknown" user and the 2nd "everyone" user.

The reason you get this everyone problem twice, is that there are actually 2 everyones. One seems to be a "group" named everyone, and one is outside world users. Thus, you see the name everyone twice.

As for getting rid of the ACL nightmare, the following worked for me.

1. What creates the ACL problem?
You can see it in action by creating a new user account (admin access), and create some dummy files in it. Try to change the names of these files, and no problem you can do so easily. Now go to up one directory level to your user folder, open a Get Info window on the new account you just made. You will see several users in the permission section, most likely "user", "staff", and "everyone".

Now use Get Info to apply a permission change to this new user account. For example, change the permission for "everyone" to Read Only. Then select "apply to enclosed items". Now go back to your home directory and try to change the file name of items in that account, and you will find you can't. Do a Get info on one of the files and in the permission section it says "You have custom access", instead of "You have read and write access".

You can also easily create the problem from the Terminal window, instead of the Get Info window. For example, go to your users folder using the Terminal application, and type the following in the terminal window.

chmod -R =rw,+X username

This will force Leopard to set the read and write permissions to the usual default to your user folder and to all files/folders recursively (this is what the -R is for) in your user folder (the +X will retain any execute permissions that are currently set). After doing this you will again create the problem.


2. What causes the problem?
Run the Terminal application (you should be in your home directory) and type:

ls -le

This will list all your files and folders in your home directory, along with the ACL extensions to the file permissions. On my machine I get under each "permission affected" files or folders the following additional information.

0: group:everyone deny delete

So this "everyone" person is not allowed to delete any files (or rename them). And this "everyone" person is a "group" that includes EVERYONE including the user as well. Thus, since "everyone" can't change files, neither can the user. This part is confusing at first to realize what is going on since in Unix terminology normally "everyone" only refers to the outside world, and not the user himself. I believe Apple tried to use the ACL extension to prevent certain files/folder that Leopard would not want the user to rename/delete (i.e. Pictures directory), but for some reason Leopard is applying this to all files, folder, and contents of folders.


3. The solution the solution is simple. Remove this ACL condition for all files or folders in your home directory.

3a. You typically can easily do this from the user folder level in Terminal, since the affected account also has the same ACL condition applied to it. Type ls -le to see if this condition is present for the affected user folder account itself. If it is, then all you have to do is type is:

chmod -R -a# 0 username

This will remove the ACL condition (numbered 0) from the user account folder, and all files or folders in it (the -R condition causes this recursive fix of all contents of all folders).

3b. You may not be able to do this from the user folder level in Terminal if the user folder itself does not have this ACL condition. In this case, simply go to your home directory in Terminal, and fix to each file or folder within your home directory individually, and do this recursively to all contents of folders so you don't have to do it for the contents of the folders in your home directory. Type ls -le, and find which files/folders are affected, and for each affected file/folder type the following to remove their ACL condition:

chmod -R -a# 0 file_or_folder_name

After doing this, if you type " ls -le " in Terminal window you will see that the ACL condition is gone from every fixed file or folder. Also, if you do a Get Info in Finder on any fixed file/folder you will see in the permission section the phrase "You can read and write".


Should the permission problem be fixed this way by canceling the ACL conditions, I am not sure. But it is now fixed on my machine (not solved, but fixed) and I again have full access to all my files.

[zeeb]

Hey Cy ---

You are a genius. I'm trying to perform a 'save as' to a Logic 8 file imported from 10.4.10 to 10.5.1, but even though my user(me) and admin options are showing 'read&write'/you have custom access i'm getting no joy....

I've tried ls -le and got ;

0: group:everyone deny delete , but no sign of ACL just;

'drwx------+ 4 username staff 136 Dec 12 12:45 Downloads', etc.....

I also tried the 'chmod -R -a# 0 username' in Terminal, but it tells me there is 'no ACL present'. I'm trying the second 3b part, but not sure how to navigate to my home directory in Terminal? Unfortunately, I'm a complete novice on terminal ;

"...In this case, simply go to your home directory in Terminal, and fix to each file or folder within your home directory individually, and do this recursively to all contents of folders so you don't have to do it for the contents of the folders in your home directory..."

I believe if I can get inside here I should be able to perform the fix --- and save the file i've just been working on! ...maybe.

Many thnx if you can help with the info ---

Cheers,

John

[Las_Vegas]

drwx------+ 4 username staff 136 Dec 12 12:45 Downloads

The plus symbol indicates ACL as does the 'group:everyone deny delete'

You cannot replace the file, but you can rename or move it. I suspect your primary problem is where the file was imported to. If the file is not in your Home directory or one of the folders therein, move it somewhere into your Home directory.

[Hal Itosis]

The 'unknown' entity in all these cases is likely the missing [user]group 501 (or 502, etc).

I don't believe any single cause has been identified yet, but somehow -- during the upgrade
and/or migration stage -- *some* Tiger users who had private groups (i.e., group 501, 502,
etc., whose group name matched their username) ended up with that group not existing in
the Directory Services database (/var/db/dslocal/nodes/Default/groups/).

So it shows up in Get Info windows as "unknown". Why changing that in Finder causes it to
crash I have no idea... but one of the simpler (relatively) solutions is to just re-create the
missing group. Another option is to change the unknowns to 'staff'. There are some threads
scattered about that discussed this... and one particular macosxhints tip arrived yesterday:

10.5: Repair a user/group Finder crashing issue (http://www.macosxhints.com/article.php?story=200711291134001)

[observe the comment by robg, and my comment there as well.]

-HI-

[Hal Itosis]

The "group:everyone deny delete" ACL is another matter. That entry actually *belongs* on
certain Apple default user folders (Desktop, Documents, Downloads, Library, Movies, Music,
Pictures, Public, Sites... and the user's Home folder itself). If we try to delete one of those
folders, a password will be requested. [Not sure if that will actually allow the deletion.]

Anyway, I guess it's harmless enough to remove them all... idunno. I'd rather just remove
them from folders where they don't belong. (In fact... I actually *added* that entry to my
own ~/Applications and ~/bin).

Nonetheless, I believe the command:chmod -R -N ~ will clear all ACLs from our Home.

-HI-

[CharlotteWeimar]

After installing Leopard on my new six month old iMac my User ID was lost and access denied to many files. Created a new ID and was able to get some access. But iPhoto library says 'Lost" although the images show in "all images" but are not accessible; iTunes is not there and Mail was empty. Had 30 minute call to 'Mac help' and was talked through a useless routine. Decided to copy all to an external HD, created a new ID and now have access to Mail & to iPhoto and iTunes when the HD is connected. Will Mac sort his out with software updates?

[Hal Itosis]

After installing Leopard on my new six month old iMac my User ID was lost and access denied to many files.
Did you do a "clean" install (erase the HD and import your docs with
Migration Assistant at the initial restart after installation), or did you
upgrade over Tiger with all user accounts remaining in place on the HD?



Created a new ID and was able to get some access. But iPhoto library says 'Lost" although the images show in "all images" but are not accessible; iTunes is not there and Mail was empty. Had 30 minute call to 'Mac help' and was talked through a useless routine. Decided to copy all to an external HD, created a new ID and now have access to Mail & to iPhoto and iTunes when the HD is connected.
More than likely, the perms on your docs don't match properly with those of your account.
Depending on how you installed, there are a few ways to fix this. Some of them will likely
be facilitated by using Terminal (both for changing things and also for communicating to us
the current conditions).



Will Mac sort this out with software updates?
If my guess is right, and your permissions are mismatched... then neither a software
update nor Apple's Disk Utility (to repair permissions) are of much value here. [When
I say "permissions", I'm also referring to owner ID and primary group assignment, etc.]

Perhaps if you do a clean install and migrate your stuff from a backup disk,
that could work. Not able to say much more about what I can't actually see.

-HI-

[mediter]

I accidentally messed up the Applications folder, by assigning different privileges to the default applications. I tried to remove the ACL files by using the command "sudo find <in-folder> -exec chmod -a# 0 {} +". But it didn't help. When executing this command in Terminal, it says "No ACLs Present". However, when use "ls -le" to check it out, it still reads that little plus symbol after the permissions.

[Hal Itosis]

Should only be the "/Applications" folder itself and the "/Applications/Utilities" folder
that have ACLs anyway. Anyway... if you've added a bunch, then my Dec. 13th post
should indicate a way to do it without 'find'. (And the syntax you posted doesn't look
right either; what's the + for?). I would think sudo chmod -R -N /Applications is
all it would take (but then you'll need to add ACLs back on the 2 folders I mentioned).

[JadeIIII]

Same problem...

Also, when Time Machine is backing up, my laptop (mbp 2gig ram 2.16ghz) often locks up, becomes unresponsive, or acts really strange...

Anybody else experience this? I bought a brand new lacie hd when leopard came out for Time Machine, and it has all of the latest updates...

I really hope some of these issues are resolved soon...

bye,
David

[Hal Itosis]

Same exact acl problem... Will apple fix this?
I really hope some of these issues are resolved soon...

The issues discussed in this thread happened to a relative minority of users,
most (if not all) of whom did an "upgrade" rather than a clean install. The more
time that passes, the *less* likely Apple will care about such cases... as more
and more Leopard installs will be done cleanly. If it ever is "fixed", it will be in
the form of a 10.5.x DVD... that future (new) users will purchase.

Why don't you just do a clean install? [erase HD, migrate from backup]

As far as MacBookPro, Time Machine and LaCie goes... I have that exact setup,
with zero problems. Most likely, a clean install will be good for that too.

[Madison_Carl]

I’m a new subscriber, and a novice in dealing with UNIX level modifications of my Mac. I’ve run headlong into one of the permissions problems that have plagued new Leopard users, and I’ve tried to follow many of the user forums on the subject, but with admitted mixed levels of understanding. My problem seems to have a twist that I’ve not seen addressed in the forums, and I’m hoping you or one of the forum readers will be able to help.

My MacPro has six hard drives, four internal, and two external. Two of the internal, and both of the external drives show on the desktop as having the usual hard-drive icon, but also has a small “Yale lock” shown in the lower left hand corner of the icon. A get info shows that I (administrator) do not have write privileges on these four locked drives.

The following is a list of my UNIX level settings gleaned from the Terminal.

carl-j-bowsers-mac-pro:/ cbowser$ cd Users
carl-j-bowsers-mac-pro:Users cbowser$ ls -la
total 0
drwxr-xr-x 9 root admin 306 Jan 8 20:07 .
drwxrwxr-x 48 root admin 1700 Jan 6 09:30 ..
-rw-r--r-- 1 root wheel 0 Sep 23 19:43 .localized
drwxrwxr-x 13 root admin 442 Jan 8 12:47 Carlos
drwxr-xr-x 12 Guest _guest 408 Jan 8 20:07 Guest
drwxrwxrwt 14 root wheel 476 Jan 6 02:02 Shared
drwxrwxr-x 16 root admin 544 Jan 7 21:22 bowser
drwxrwxr-x 16 carlbowser admin 544 Jan 8 12:00 carlbowser
drwxrwxr-x 27 cbowser admin 918 Jan 9 14:19 cbowser

carl-j-bowsers-mac-pro:Users cbowser$ cd /Volumes
carl-j-bowsers-mac-pro:Volumes cbowser$ ls -la
total 8
drwxrwxrwt@ 8 root admin 272 Jan 9 09:43 .
drwxrwxr-x 48 root admin 1700 Jan 6 09:30 ..
drwxrwxr-x+ 14 root admin 544 Dec 19 09:06 Backup_external
drwxrwxr-x@ 42 cbowser cbowser 1496 Jan 3 09:31 LaCie Disk
lrwxr-xr-x 1 root admin 1 Jan 9 09:42 Leopard HD -> /
drwxrwxr-x@ 49 cbowser cbowser 1734 Jan 9 09:12 Macintosh HD
drwxrwxr-x@ 14 cbowser cbowser 544 Dec 31 14:01 Photos
drwxrwxr-x+ 20 cbowser cbowser 748 Jan 3 09:27 Photos Backups

carl-j-bowsers-mac-pro:Volumes cbowser$ whoami
cbowser


Using “Get Info for the six drives reveals that three of the four locked drives have “(unknown)” as a user. They are: Photos, Photos Backups, and LaCie Disk. Another unlocked disk has the unknown user, and that is the disk on which resides a bootable Tiger shell. Further I have absolutely no idea who “wheel” is. Suggestions?

I’d like to remove the locked icons and return permissions to the admin account (cbowser). Any suggestions you could offer would be appreciated immensely.

A suggested script using my username and procedural approach would give me that confidence to try what I’m at this point unwilling to try for fear of doing irreversible harm.

Thanks, Carl

[Hal Itosis]

Further I have absolutely no idea who “wheel” is.

Wheel is to groups as root is to users. Its gid is 0 (zero).
Actually, both items shown in your lists with "wheel" look 100% correct.

These listed user folders have wrong ownerships:
drwxrwxr-x 13 root admin 442 Jan 8 12:47 Carlos
drwxrwxr-x 16 root admin 544 Jan 7 21:22 bowser

These listed user folders have *atypical* groups (as do the above):
drwxrwxr-x 16 carlbowser admin 544 Jan 8 12:00 carlbowser
drwxrwxr-x 27 cbowser admin 918 Jan 9 14:19 cbowser
...but, I suppose that's doable.

These volumes (which you say appear locked?) are... interesting:
drwxrwxr-x@ 42 cbowser cbowser 1496 Jan 3 09:31 LaCie Disk
drwxrwxr-x@ 49 cbowser cbowser 1734 Jan 9 09:12 Macintosh HD
drwxrwxr-x@ 14 cbowser cbowser 544 Dec 31 14:01 Photos
drwxrwxr-x+ 20 cbowser cbowser 748 Jan 3 09:27 Photos Backups

Apparently "Photos Backups" has an ACL... and -- for all we know --
the others may also have ACLs. Unfortunately, the @ overrides the +
when ls displays that string... so there's no way to be sure unless we
explicitly tell ls to show us any ACLs. Also... there may be flags which
have locked these disks... but we need to tell ls to display them.

Do it again with the -e and the -O options: ls -lkbaeO /Volumes
[that's an uppercase o... not a zero.]

While you're there, the id command will show some info whoami missed.

[Madison_Carl]

Thanks to Hal_Itosis for hints and a local UNIX expert who helped identify the problem. Three and a half hours with a very patient and helpful Apple expert I have unlocked the four offending drives. I offer this summary in the hopes that it might help others with a similar problem.

The helpful woman who finally led me to a "sudo" session with the terminal found the solution on the web page: http://docs.info.apple.com/article.html?artnum=106237.

Procedure:
1) Unplug my external drives and restart the MacPro

2) Using terminal I used the following command for each of the offending, internal drives with the lock symbol.

sudo chflags -R nouchg 'volume name'

That cleared the locked icon for the internal drives, and I then transferred all files from the external "locked" drives then reformatted them with Apples "Disk Utility".

Using 'Disk Utility' the two external volumes show that the S.M.A.R.T. Status is 'Not supported' and the Partition Map Scheme is set to 'Apple Partition Map'.
The internal drives have S.M.A.R.T. Status as 'Verified' and the Partition Map Scheme set at 'GUID Partition Table'. I'm not sure why the two are different, and would appreciate any insights any of you experienced UNIX-Leopard users may have.

Thanks again Hal.

[johnsawyercjs]

Using 'Disk Utility' the two external volumes show that the S.M.A.R.T. Status is 'Not supported' and the Partition Map Scheme is set to 'Apple Partition Map'.
The internal drives have S.M.A.R.T. Status as 'Verified' and the Partition Map Scheme set at 'GUID Partition Table'. I'm not sure why the two are different, and would appreciate any insights any of you experienced UNIX-Leopard users may have.

SMART isn't supported for Firewire or USB drives--only for drives directly connected to the ATA or SATA bus.

APM is Apple's older partitioning scheme; GUID is the newer scheme, used with Intel-based Macs, but Intel Macs work properly with APM, but not as a startup volume--Intel Macs can start up from an APM volume, but some things won't work right, and you can't install OS X onto an APM volume that's connected to an Intel Mac. Your internal drives are partitioned as GUID since your Mac is Intel-based. Your external drives may predate your Intel Mac; they'll work fine as APM, so though they can be re-initialized as GUID, there's no need to, unless you want to install or copy OS X onto them.

[2luxe]

Maybe a tip for someone: there's a freeware app which removes the ACLs from a specified folder:
ACL fix (http://www.xnation.net/)
This one saved me much time… :)

[gosscl]

The "group:everyone deny delete" ACL is another matter. That entry actually *belongs* on
certain Apple default user folders (Desktop, Documents, Downloads, Library, Movies, Music,
Pictures, Public, Sites... and the user's Home folder itself). If we try to delete one of those
folders, a password will be requested. [Not sure if that will actually allow the deletion.]

Anyway, I guess it's harmless enough to remove them all... idunno. I'd rather just remove
them from folders where they don't belong. (In fact... I actually *added* that entry to my
own ~/Applications and ~/bin).


Nonetheless, I believe the command:chmod -R -N ~ will clear all ACLs from our Home.

-HI-

I had this problem with MacOS 10.5.x up to & including 10.5.2.
All data files in my home folder were unable to be edited & resaved.

Apple care tech's asked me to do chmod -R to my home folder.
It did not work.

I tried your suggestion of chmod -R -N ~ and bingo it worked.
What does chmod -R -N ~ do?
The -N switch is not documented in the man page of my system. What is it?

[Hal Itosis]

The -N switch is not documented in the man page of my system. What is it?

All the way at the bottom (just above Compatibility):
-N Removes the ACL from the named file(s).

If your Leopard man page does *not* have that, I'll bet 50¢ you did an upgrade over Tiger,
rather than a clean install. [see: "odd man page question... (http://forums.macosxhints.com/showthread.php?t=80860)"]

-HI-

[drdoof]

I seem to have unwanted ACL on EVERY file on my boot drive (10.5.3). Disc Utility has already gone for 15 hours repairing permissions and is only 2/3 finished. This happened after I let software update do it's thing updating to 10.5.4 on a separate install of Leopard that I use for troubleshooting the boot drive. This is on a MacPro that I've had for only 2 months. Already I've had to deal with my hard drive toggling its invisibility flag, as well as the double user 'custom access' situation with all external drives locked. What next??

Any solutions to the ACL problem would be most welcome. I'm a composer, and I just finished setting up and authorising many audio applications, and I don't particularly want to do it all over again :)

[renegade01]

Wheel is to groups as root is to users. Its gid is 0 (zero).
Actually, both items shown in your lists with "wheel" look 100% correct.

These listed user folders have wrong ownerships:
drwxrwxr-x 13 root admin 442 Jan 8 12:47 Carlos
drwxrwxr-x 16 root admin 544 Jan 7 21:22 bowser

These listed user folders have *atypical* groups (as do the above):
drwxrwxr-x 16 carlbowser admin 544 Jan 8 12:00 carlbowser
drwxrwxr-x 27 cbowser admin 918 Jan 9 14:19 cbowser
...but, I suppose that's doable.

These volumes (which you say appear locked?) are... interesting:
drwxrwxr-x@ 42 cbowser cbowser 1496 Jan 3 09:31 LaCie Disk
drwxrwxr-x@ 49 cbowser cbowser 1734 Jan 9 09:12 Macintosh HD
drwxrwxr-x@ 14 cbowser cbowser 544 Dec 31 14:01 Photos
drwxrwxr-x+ 20 cbowser cbowser 748 Jan 3 09:27 Photos Backups

Apparently "Photos Backups" has an ACL... and -- for all we know --
the others may also have ACLs. Unfortunately, the @ overrides the +
when ls displays that string... so there's no way to be sure unless we
explicitly tell ls to show us any ACLs. Also... there may be flags which
have locked these disks... but we need to tell ls to display them.

Do it again with the -e and the -O options: ls -lkbaeO /Volumes
[that's an uppercase o... not a zero.]

While you're there, the id command will show some info whoami missed.
Hal, I've run into the same problem that Madison_Carl had with Followup to "locked icon" permission problem" on 01/18/2008. When I try the command sudo chflags -R nouchg 'volume name', I receive:

Password:
chflags: MP_Storage: No such file or directory

[Process completed]

...is there something I'm overlooking? Thanks...

[Hal Itosis]

...is there something I'm overlooking? Thanks...
Apparently you overlooked this:
Do it again with the -e and the -O options: ls -lkbaeO /Volumes
[that's an uppercase o... not a zero.]

While you're there, the id command will show some info whoami missed.
[we need to at least *see* what it is we're talking about]

[renegade01]

...this is the information that resulted:

Last login: Wed Nov 25 03:21:16 on console
MacPro:~ pete$ ls -lkbaeO /Volumes
total 4
drwxrwxrwt@ 12 root admin hidden 408 Nov 25 03:20 .
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxr-t+ 51 root admin - 1802 Nov 25 00:36 ..
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drw-rw-rw-@ 45 pete pete uchg 1598 Nov 22 11:37 MP Storage
0: user:pete allow list,add_file,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity
drw-rw-rw-@ 20 pete pete uchg 748 Nov 21 10:05 MP-AV
0: user:pete allow list,add_file,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity
drw-rw-rw-@ 18 pete pete uchg 680 Oct 12 05:28 MP-EyeTV
0: user:pete allow list,add_file,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity
drw-rw-rw-@ 42 pete pete uchg 1496 Nov 11 20:58 MP-Movies
0: user:pete allow list,add_file,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity
lrwxr-xr-x 1 root admin - 1 Nov 25 03:20 MacPro HD -> /
drwxrwxrwx+ 3 petruk 501 - 102 Jul 8 18:40 Pics&Vids-BU
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxrwx+ 3 petruk 501 - 102 Jul 12 09:55 Pics&Vids-BU 1
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxrwx+ 3 petruk 501 - 102 Aug 13 20:55 Pics&Vids-BU 2
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxrwx+ 3 petruk 501 - 102 Sep 9 19:08 Pics&Vids-BU 3
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxrwx+ 3 petruk 501 - 102 Oct 12 05:32 Pics&Vids-BU 4
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
MacPro:~ pete$ id
uid=502(pete) gid=502(pete) groups=502(pete),98(_lpadmin),80(admin)
MacPro:~ pete$

...please note that I have little familiarity w/Terminal...thanks...

Pete
dispatched at 8:35 pm, Wednesday, 25 November

[hayne]

Looks like the name of the drive/partition in question is "MP Storage" (with a space, not an underscore like you apparently had before).
Since the name has a space in it, you will need to enclose the full path in quotes:
"/Volumes/MP Storage" in any commands you use (e.g. 'chflags')

[renegade01]

...I thought something was amiss because I had a space in the hard drive name. Unfortunately, when I tried:

sudo chflags -R nouchg "/Volumes/MP Storage"

...it resulted in this:

Password:
chflags: "/Volumes/MP: No such file or directory
chflags: Storage": No such file or directory

[Process completed]

[hayne]

...I thought something was amiss because I had a space in the hard drive name. Unfortunately, when I tried:

sudo chflags -R nouchg "/Volumes/MP Storage"

...it resulted in this:

Password:
chflags: "/Volumes/MP: No such file or directory
chflags: Storage": No such file or directory

[Process completed]

That's a bit like what you would get if you omitted the quotes.
But the quotes are showing up in the results messages. Maybe you are typing some other character than a regular quote character.
Please show us (via the copy & paste from the Terminal window) exactly what commands you are running and their results. Just copy & paste it - don't edit it at all.

[Hal Itosis]

MacPro:~ pete$ ls -lkbaeO /Volumes
total 4

drwxrwxrwt@ 12 root admin hidden 408 Nov 25 03:20 .
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity

drwxrwxr-t+ 51 root admin - 1802 Nov 25 00:36 ..
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity

drw-rw-rw-@ 45 pete pete uchg 1598 Nov 22 11:37 MP Storage
0: user:pete allow list,add_file,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity

drw-rw-rw-@ 20 pete pete uchg 748 Nov 21 10:05 MP-AV
0: user:pete allow list,add_file,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity

drw-rw-rw-@ 18 pete pete uchg 680 Oct 12 05:28 MP-EyeTV
0: user:pete allow list,add_file,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity

drw-rw-rw-@ 42 pete pete uchg 1496 Nov 11 20:58 MP-Movies
0: user:pete allow list,add_file,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity

lrwxr-xr-x 1 root admin - 1 Nov 25 03:20 MacPro HD -> /
<snip>

All 4 of those "MP" volumes (MP Storage, MP-AV, MP-EyeTV, MP-Movies) are locked with a uchg flag AND zero search access (no x bit).

So... we may as well tweak them en masse:

chflags nouchg /Volumes/MP*; chmod a+x /Volumes/MP*

From the looks of things (ownership), sudo won't be needed... but if "permission denied" messages appear, just add sudo before each chmod. [e.g., sudo chflags nouchg /Volumes/MP*; sudo chmod a+x /Volumes/MP*]

Those ACLs look unnecessary as well, but since they're of the 'allow' variety i guess leaving them there won't hurt none.

[brunitou]

All I know (without reading all the posts) is that there's some "bug" with Leopard upgraded from Tiger (my case on my iMac): the user groups are not the same. So there's often some "unknow user". (source: http://pinkmutant.com/articles/Leopard/leobugs.html )

I remember having success with deleting the unknow user, then chmod 000, then add the users in the GUI (cmd-i). But for the unknow user should remain for network access I think.

[renegade01]

...Hal, I copy/pasted your suggestion. It resulted in this:

-chflags: /Volumes/MP*;: No such file or directory
-chflags: chmod: No such file or directory
-chflags: a+x: No such file or directory
-chflags: /Volumes/MP*: No such file or directory

[Process completed]

...let me backtrack to explain how I got in this predicament. I bought a new Mac and was used the Migration Assistant to transfer apps and data (petruk). Unfortunately, I used a different name for the Admin (pete) when I first setup the new Mac, so I ended up w/two Admins...

...this was an annoyance because Mail and iTunes wouldn't remember my password. So, I tried to transfer ownership from petruk to pete via Get Info, then change all permissions to Read/Write, then Apply to enclosed items. What resulted was two users named Pete, one (unknown) and one group (everyone) - all with Custom Privilege. I can see the drive icon but when I double-click on it, it replies that I can't open it because I don't have sufficient privileges...

...so, if I really FUBRed, I have backup copies of the drives. I can reformat and start from scratch. Was hoping to avoid the laborious process but if I gotta, I gotta...

...thanks so much again for your help...

Pete
dispatched at 9:15 am, Thursday, 26 November
Thanksgiving Day

[hayne]

...Hal, I copy/pasted your suggestion. It resulted in this:

-chflags: /Volumes/MP*;: No such file or directory
-chflags: chmod: No such file or directory
-chflags: a+x: No such file or directory
-chflags: /Volumes/MP*: No such file or directory

[Process completed]

Once again (see my post above), I ask that you copy & paste the full contents of your Terminal window so we can see the commands you ran, your prompt and all, as well as the results of those commands.

[Hal Itosis]

...Hal, I copy/pasted your suggestion. It resulted in this: -chflags: /Volumes/MP*;: No such file or directory

It helps to have those volumes mounted *before* running the commands. :)

According to ls -lkbaeO, those disks all start with the basic ASCII chars "MP".
[if there were some hidden chars, then -b would have revealed that].

If MP* doesn't match anything, then... either those disks weren't mounted or, permissions are the least of your problems. :cool:



-chflags: chmod: No such file or directory

Huh? Dude... when i post a command line, use copy/paste. Don't go improvising on me. :D
[you omitted the semicolon;]

[renegade01]

Hal, the volumes are mounted. They appear on my desktop. When I double-click on any of them, they reply:

The folder "MP Storage" could not be opened because you do not have sufficient access privileges

I'm guessing that the this isn't a good thing

[Hal Itosis]

chflags nouchg /Volumes/MP*; chmod a+x /Volumes/MP*

[renegade01]

EUREKA!!!! IT WORKED (sorta)...

Hayne, initially I copy/pasted sudo chflags -R nouchg "/Volumes/MP Storage" into Shell->New Command and it didn't work. But when I copy/pasted into a Terminal window, it worked successfully - the drives are now accessible. Thank you...

If I can impose on you or Hal one more time. I still have an inaccessible external HD named Pics&Vids-BU. What would be the unlock command for that? I tried the previous command but it did not work. Thanks...

[hayne]

I still have an inaccessible external HD named Pics&Vids-BU. What would be the unlock command for that? I tried the previous command but it did not work.

You need to show us what you tried (show via copy & paste of full contents of Terminal window), not tell us about it.

[renegade01]

...my bad...

Last login: Thu Nov 26 21:36:26 on ttys000
MacPro:~ pete$ sudo chflags -R nouchg "/Volumes/Pics&Vids-BU"
Password:
MacPro:~ pete$

...also tried this:

Last login: Thu Nov 26 21:25:25 on console
MacPro:~ pete$ sudo chflags -R nouchg "/Pics&Vids-BU"
Password:
chflags: /Pics&Vids-BU: No such file or directory
MacPro:~ pete$

[Hal Itosis]

EUREKA!!!! IT WORKED (sorta)...

Hayne, initially I copy/pasted sudo chflags -R nouchg "/Volumes/MP Storage" into Shell->New Command and it didn't work. But when I copy/pasted into a Terminal window, it worked successfully - the drives are now accessible. Thank you...

If I can impose on you or Hal one more time. I still have an inaccessible external HD named Pics&Vids-BU. What would be the unlock command for that? I tried the previous command but it did not work. Thanks...

So, you're saying that MP-AV, MP-EyeTV, and MP-Movies are all unlocked now?

Okay... i'll go re-read my Unix books. [musta missed something] ;)

[BTW, since petruk owns those 4 /Pics&Vids-BU* volumes, you might want to try sudo chown pete /Pics&Vids-BU* on those.]

[renegade01]

...don't sweat it, Hal. Since I'm not familiar w/UNIX, I'm most grateful for any help I get. If Hayne's suggestion didn't work, I would have tried yours next...

[hayne]

MacPro:~ pete$ sudo chflags -R nouchg "/Volumes/Pics&Vids-BU"
Password:
MacPro:~ pete$



If you didn't get any error message after that command (as it seems), then it presumably worked.
Do you still have a problem with that drive/partition?
If so, please show us again the results of:

ls -lkbaeO /Volumes

[renegade01]

Pics&Vids-BU is inaccessible but mounted...

Last login: Thu Nov 26 22:30:43 on console
MacPro:~ pete$ ls -lkbaeO /Volumes
total 4
drwxrwxrwt@ 14 root admin hidden 476 Nov 26 22:30 .
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxr-t+ 51 root admin - 1802 Nov 25 00:36 ..
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxrwx@ 45 pete pete - 1598 Nov 22 11:37 MP Storage
drwxrwxrwx@ 20 petruk 501 - 748 Nov 21 10:05 MP-AV
drwxrwxrwx@ 18 pete pete - 680 Oct 12 05:28 MP-EyeTV
drwxrwxrwx@ 42 pete pete - 1496 Nov 11 20:58 MP-Movies
lrwxr-xr-x 1 root admin - 1 Nov 26 22:30 MacPro HD -> /
drwxrwxrwx+ 3 petruk 501 - 102 Jul 8 18:40 Pics&Vids-BU
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxrwx+ 3 petruk 501 - 102 Jul 12 09:55 Pics&Vids-BU 1
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxrwx+ 3 petruk 501 - 102 Aug 13 20:55 Pics&Vids-BU 2
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxrwx+ 3 petruk 501 - 102 Sep 9 19:08 Pics&Vids-BU 3
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxrwx+ 3 petruk 501 - 102 Oct 12 05:32 Pics&Vids-BU 4
0: user:pete allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drw-rw-rw-@ 14 petruk 501 uchg 544 Nov 21 10:05 Pics&Vids-BU 5
0: user:pete allow list,add_file,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxr-x 11 pete pete - 442 Nov 26 21:21 TM-700ide
MacPro:~ pete$

[hayne]

1) You seem to have a bunch of copies (1, 2, 3, etc) of the Pics&Vid-BU stuff under /Volumes.
Unless you have several similarly named drives, this is likely detritus left over in the /Volumes folder from some previous incident when a mounted drive was not properly unmounted.

First unmount and physically disconnect all external drives and network drives.
(To be really safe, disconnect all network cables and turn off Airport.)
Then use the menu item "Go to Folder..." from Finder's "Go" menu, and then type in "/Volumes" (without the quotes).

Look at the contents of the /Volumes folder.
If you see anything other than the one entry for your internal drive**, that is likely the detritus I spoke of above.

Use Finder to trash the left over folders from /Volumes. (If you are sure that no external disks or network drives are connected then this can't affect what is on the external disks.) Finally, empty the Trash.

** If you have more than one internal drive, or multiple internal partitions, you will of course see them as well - don't delete them!


2) I'm not sure, but I think the access problem with your drive is likely due to the ACLs that are applied to it. (they show in the above listing after the line with the drive name)
So maybe removing those ACLs is the next step. I'm not up on how to do this, so google for instructions or wait for someone else to pipe in here.

[renegade01]

BINGO! That did the trick...

...disconnected the external HDs, used Go to Folder /Volumes to search and destroy the detritus. Reconnected the drives and it was still locked...

...but then I remembered and ran:

Last login: Thu Nov 26 23:17:04 on console
MacPro:~ pete$ sudo chflags -R nouchg "/Volumes/Pics&Vids-BU"
Password:
MacPro:~ pete$

...this time it worked. Thanks again...I remain in your debt...

[Hal Itosis]

...don't sweat it, Hal. Since I'm not familiar w/UNIX, I'm most grateful for any help I get. If Hayne's suggestion didn't work, I would have tried yours next...
Well apparently something fixed MP-AV, MP-EyeTV, and MP-Movies (along with MP Storage):


drwxrwxrwx@ 45 pete pete - 1598 Nov 22 11:37 MP Storage
drwxrwxrwx@ 20 petruk 501 - 748 Nov 21 10:05 MP-AV
drwxrwxrwx@ 18 pete pete - 680 Oct 12 05:28 MP-EyeTV
drwxrwxrwx@ 42 pete pete - 1496 Nov 11 20:58 MP-Movies

...as their 'x' bits are all restored now. Indications are that my "chmod a+x /Volumes/MP*" did manage to run successfully (at some point), and perhaps you didn't realize it. [i.e., no amount of "chflags" could have ever accomplished that... and no amount of anything applied to "MP Storage" alone would have affected the other three MP* disks.]

Don't sweat it.

[mathematrucker]

This thread seems close enough to my permissions issue to go ahead and post. A month ago I installed Snow Leopard on my MacBook Pro. Installation went fine. A little over a week ago when RealPlayer wasn't displaying a certain video from a website I used Disk Utility to "repair permissions" per some troubleshooting steps found online.

Not sure if that's what caused this, but now my hard drive's Get Info says "You have custom access." Thankfully, to fix the problem all I need do is click the lock icon and enter my password to ungray all the "Read and Write"s.

But is there an easy way to get things back to where I won't have to do this every time I start up the machine? If not, I may write a QuicKeys startup macro to automatically handle the unlock.

[trevor]

Can we see the output from the commands below, copy/pasted into your Terminal program (which is found in /Applications/Utilities):

ls -lkbaeO /Volumes
id
echo "done"

Trevor

[tlarkin]

I just want to point out, that not too long ago I discovered that the ACL in a user's home folder with the everyone:deny set, is actually default in OS X 10.5. Since OS X will use POSIX over ACL.

It really freaked me out too the first time I saw it, but when I was on the phone with Enterprise support on a different issue I brought it up and asked how my ACLs kept getting all jacked up, and they said that is how it behaves by default...

[Hal Itosis]

I just want to point out, that not too long ago I discovered that the ACL in a user's home folder with the everyone:deny set, is actually default in OS X 10.5. Since OS X will use POSIX over ACL.
That is inaccurate.

Yes, Leopard did default to including group:everyone deny delete on some 37 folders scattered about inside a user's home. But, where does "OS X will use POSIX over ACL" come from? If we try to delete our Movies folder for example (which we own and have full rwx privs for) we are immediately denied. If OSX were using POSIX over ACL, then that folder would instead fly into the trash on demand.

What does happen is: a dialog requesting an admin password comes up, and (if a valid admin password is entered), then -- and only then -- is the Movies folder transported to the trash. IOW, "everyone" means everyone except root... so only admins who can authorize are allowed to (ask root to) delete those items.


edit: i will grant that -- once such ACL-laden objects (including heavily guarded items from the Time Machine backup area) are placed into a user's trash -- emptying the trash (actual deletion) seems to proceed totally unimpeded. Perhaps there's something of what you say in effect, where items already inside the trash are concerned.

[mathematrucker]

Can we see the output from the commands below, copy/pasted into your Terminal program (which is found in /Applications/Utilities):

ls -lkbaeO /Volumes
id
echo "done"

Trevor

Here's what came up when the above lines were pasted into Terminal:

Last login: Wed Dec 2 07:51:55 on console
68-29-185-241:~ mark$ ls -lkbaeO /Volumes
total 4
drwxrwxrwt@ 3 root admin hidden 102 Dec 2 09:55 .
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit
drwxrwxrwx@ 34 root admin - 1224 Dec 1 10:54 ..
lrwxr-xr-x 1 root admin - 1 Dec 2 07:51 Macintosh HD -> /
68-29-185-241:~ mark$ id
uid=502(mark) gid=20(staff) groups=20(staff),101(com.apple.sharepoint.group.1),204(_developer),100(_lpoperator),98(_lpadmin),81(_appserveradm),80(ad min),79(_appserverusr),61(localaccounts),12(everyone),102(com.apple.sharepoint.group.2),401(com.apple.access_screenshari ng)
68-29-185-241:~ mark$ echo "done"

[tlarkin]

Sorry Hal, I mean it prefers it over an ACL. That is what Apple told me. ACLs can still deny access to POSIX settings.

[Hal Itosis]

Sorry Hal, I mean it prefers it over an ACL.
What does that mean though? :confused:

ACLs -- by definition -- get evaluated first, and always override POSIX (if any overlap or conflict exists).

That is what Apple told me.
Maybe the *person* you spoke to prefers POSIX to ACLs. :D

[tlarkin]

It means that ACLs were known to have issues, and if you had ACLs on nested folders your issues were more likely to happen. This was coming from Tier 2 paid tech support with Apple. I got to assume the guy on the other end knows what he is talking about.

I have had ACLs botch a few times and of course my environment is a lot different than most people's. Most places of business don't have 8,000 Macs connecting to 35 servers. Some of the problems I see are specific to my environment.

[Hal Itosis]

Guess i'll be the bearer of bad news...
Here's what came up when the above lines were pasted into Terminal:

68-29-185-241:~ mark$ ls -lkbaeO /Volumes
total 4
drwxrwxrwt@ 3 root admin hidden 102 Dec 2 09:55 .
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

Ouch. That's a pretty severe ACL to be placed on /Volumes... with inheritance no less!!! :eek:

How in blazes did that get there??? And, i wonder how deep into any previously mounted volumes it may have already propagated. [hmm, now i need to think. -- EDIT: the more i think about that one, the weirder it gets. Why on Earth would any program or person do that? It appears to be ingeniously aimed at *mounted* volumes.]

Oh well, it's your baby trevor. ;)

EDIT: Though, i suppose
sudo chmod -N /Volumes
would be a good place to start.

[Hal Itosis]

It means that ACLs were known to have issues, and if you had ACLs on nested folders your issues were more likely to happen. This was coming from Tier 2 paid tech support with Apple. I got to assume the guy on the other end knows what he is talking about.

Okay, "issues"[?]. Hmm.

Well still, the phrases 'OSX will use POSIX over ACL' and 'it prefers it over an ACL' both seem to lose something in translation. (I guess knowing is one thing and communicating knowledge is another... because i don't quite follow).

[tlarkin]

Okay, "issues"[?]. Hmm.

Well still, the phrases 'OSX will use POSIX over ACL' and 'it prefers it over an ACL' both seem to lose something in translation. (I guess knowing is one thing and communicating knowledge is another... because i don't quite follow).

Well I don't know how to explain it any better other than, POSIX is the 'preferred' method and ACLs can be a huge pain. Pick up a Peachpit Press book on any of the OS X Server certification guides, and there are many claims to how big of a pain ACLs can be. This is coming from third party, not from Apple.

I use ACLs and they work, but I keep it simple and don't have 30 sub-folders nested with in a share point that has ACLs on it.

[Hal Itosis]

$ ls -lkbaeO /Volumes
total 4
drwxrwxrwt@ 3 root admin hidden 102 Dec 2 09:55 .
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

Incredible. I don't feel like testing now to see if that ACL really works... but (in theory), if it actually manages to accomplish what it appears to be attempting -- then any mounted volume (with ACLs enabled) would effectively become unwritable to "everyone" but root. That's a pretty devilish contraption (bordering on trojan-like construction).

[trevor]

Oh well, it's your baby trevor. ;)

EDIT: Though, i suppose
sudo chmod -N /Volumes
would be a good place to start.

Works for me.

mathematrucker, open up your Terminal and copy/paste the following commands into it:

sudo chmod -N /Volumes
ls -lkbaeO /Volumes
echo "done"

Because of the 'sudo' command the preludes the chmod command, you will be asked for your admin password. As you enter it, you will not see anything reflected back to the screen. This is a normal security precaution. If you've never used 'sudo' before, you will get a warning. This is normal for the first usage of sudo only, and is nothing to worry about. Let us see the commands and results here.

Further thinking out loud--it's dangerous, but if that ACL has propagated, we might need to use
sudo chmod -RN /Volumes
which would, of course, strip all ACLs from everywhere. Which may or may not cause serious problems, I don't know, but it seems likely. And it could be argued that that command would also reduce security on some stuff that doesn't need the ACL stripped, relying only on POSIX. So, since we don't know yet if this is needed, and we don't know the full consequences of such an extreme statement, is best not to try. Yet.

Trevor

[mathematrucker]

Works for me.

mathematrucker, open up your Terminal and copy/paste the following commands into it:

sudo chmod -N /Volumes
ls -lkbaeO /Volumes
echo "done"

Trevor

Here is the result from Terminal:

Last login: Wed Dec 2 10:14:33 on ttys000
marks-macbook-pro:~ mark$ sudo chmod -N /Volumes

WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information.

To proceed, enter your password, or type Ctrl-C to abort.

Password:
marks-macbook-pro:~ mark$ sudo chmod -N /Volumes
marks-macbook-pro:~ mark$ ls -lkbaeO /Volumes
total 4
drwxrwxrwt@ 3 root admin hidden 102 Dec 2 16:21 .
drwxrwxrwx@ 34 root admin - 1224 Dec 1 10:54 ..
lrwxr-xr-x 1 root admin - 1 Dec 2 07:51 Macintosh HD -> /
marks-macbook-pro:~ mark$ echo "done"

[Hal Itosis]

So far so good.

Now, about this line:
drwxrwxrwx@ 34 root admin - 1224 Dec 1 10:54 ..

That seems to indicate that perms on "Macintosh HD" haven't been repaired in a while... at least not correctly. [there normally isn't any world write-access to /. -- EDIT: also, the sticky bit isn't set. They should be drwxrwxr-t.]
.
trevor and i both are wondering what effect that ACL may have had on other disks mounted recently. Any problem with those? [you may want to at least list them to see if any inherited ACLs managed to get passed on.]
.
has the problem and/or symptoms for which you originally joined this thread been fixed?

[mathematrucker]

has the problem and/or symptoms for which you originally joined this thread been fixed?

No. Repairing permissions (just now) didn't solve the problem. Get Info still says "You have custom access" for Macintosh HD.

Pages found by Googling "you have custom access" seem to indicate reinstalling the OS will be required. It's happened to a lot of users of earlier OS X versions, and so far that's the only fix I've found.

Doesn't seem like such a big deal, just reinstalling the OS. Just upgraded to Snow Leopard a month ago. The installation went smoothly.

I'm assuming this is why FileMaker Pro scripts cannot write to the disk, which is what I'm trying to troubleshoot. I have no problem writing to the disk otherwise - it's only when scripts try to that the problem arises.

[tlarkin]

At this point in the game I would do the following:

1) back up any and all crucial data (though you already have back ups right?).

2) Remove all ACLs of all volumes as already mentioned previously by someone else:


sudo chmod -R -N /Volumes


3) Then run repair permissions and give it a good old magic reboot.

4) see if problem is gone or still persistent.

[Hal Itosis]

No. Repairing permissions (just now) didn't solve the problem. Get Info still says "You have custom access" for Macintosh HD.
Can you do a little better? Surely there must be some mention of system, admin and everyone? Kindly post *all* the text under Sharing & Permissions in the Get Info window. [troubleshooting is hard enough without the blindfold, thanks.]

That 'custom access' business isn't necessarily the big deal you may think it is. First off, the only "access" users normally have to "Macintosh HD" is via admin group r/w (and via everyone read-only for non-admins). It's not important if some other custom access has been added (so long as it's the 'allow' variety, and not some 'deny' ACL). On the other hand, your Terminal listings thus far show no ACL on Macintosh HD at all. So it's a little odd that Get Info seems to have other ideas. (i don't trust Finder myself... Terminal is *much* more informative where permissions are concerned).

BTW, here is what you said in post #48...

Not sure if that's what caused this, but now my hard drive's Get Info says "You have custom access." Thankfully, to fix the problem all I need do is click the lock icon and enter my password to ungray all the "Read and Write"s.
"ungray all the Read and Writes"? Why would the 'Read & Writes' need to be ungreyed? My 'Read & Writes' are grey, no problem here. What matters is that they are Read & Write' for system, and 'Read & Write' for admin. Being grey is normal (until we authorize by clicking the padlock).




I'm assuming this is why FileMaker Pro scripts cannot write to the disk, which is what I'm trying to troubleshoot. I have no problem writing to the disk otherwise - it's only when scripts try to that the problem arises.

Well i won't assume anything. I will instead ask: where exactly does FileMaker Pro have problems writing files? [full pathname please] -- And, what does the ls -lkbaeO command reveal about that target folder? [or, perhaps FMP needs to be reinstalled, due to your Snow Leopard upgrade?]

I must say, i have a hard time believing that FileMaker Pro *alone* is having trouble because of some Finder weirdness (apparently invisible to Terminal) on Macintosh HD.

EDIT: For all we know, that "custom" stuff is because of the world write-access which we clearly saw on Macintosh HD above. If you need to set world write-access on your HD for FMP to work, then something is wrong with FMP. Having world write-access on our HDs is abnormal (i.e., "custom"), and also represents a security risk.

You may want to take frequent readings with Terminal, to determine if the perms there are changing over time (restarts, etc.). In fact, can we see a listing now? Thanks.

[Hal Itosis]

No. Repairing permissions (just now) didn't solve the problem.
Did the DURP report any ACLs anywhere?
If so... where?
If no, let us know.

[Hal Itosis]

2) Remove all ACLs of all volumes as already mentioned previously by someone else:

sudo chmod -R -N /Volumes

He would need to mount some disk(s) first, for that to do anything... no?

Thus far, mathematrucker's listings reveal no mounted volumes (nor have we heard of any, despite several inquiries). And the /Volumes folder itself was just cleared of ACLs.

I don't believe unmounted volumes are affecting FMP, ;) (which seems to be the only problem mentioned, thus far).

[tlarkin]

It would have to be mounted, and if it were a network volume it could be getting those ACLs from the host of that volume.

I guess I did not realize these were mounted shares.

[Hal Itosis]

It would be helpful to know if yesterday's permissions repair reported *any* ACLs.

As post #63 suggested, i googled the "custom access" threads. They all seem to deal with bad access to items inside a user's home (not the root-level HD itself).

The most interesting mystery here is where did that one bizarre ACL we did find come from... and where (if anywhere) did it spread to?

[mathematrucker]

At this point in the game I would do the following:

1) back up any and all crucial data (though you already have back ups right?).

2) Remove all ACLs of all volumes as already mentioned previously by someone else:


sudo chmod -R -N /Volumes


3) Then run repair permissions and give it a good old magic reboot.

4) see if problem is gone or still persistent.

Carrying out this exact sequence of steps (yes I do regular backups) may have solved the problem because the FMP script just now wrote a file to Macintosh HD.

If the problem ever reappears I'll do the same steps over again. Very grateful for all the responses. Thank you very much to everyone who replied to my posts.

It sounded like there may be a loose end or two having to do with my ACLs. Not sure if this will shed any light, but when I repaired permissions, this warning appeared (this is actually from a couple days ago but the same thing appeared again today):

Repairing permissions for “Macintosh HD”
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.
ACL missing on "Volumes".
Repaired "Volumes".

Permissions repair complete

Mount Point : / Capacity : 199.71 GB (199,705,673,728 Bytes)
Format : Mac OS Extended (Journaled) Available : 139.45 GB (139,447,422,976 Bytes)
Owners Enabled : Yes Used : 60.26 GB (60,258,250,752 Bytes)
Number of Folders : 144,629 Number of Files : 632,361

Thanks again,

-math

[Hal Itosis]

Musta been that "good old magic reboot".

[mathematrucker]

Musta been that "good old magic reboot".

Actually, it turns out the problem isn't quite solved yet after all. But it must have been partially solved, because I'm nearly certain FMP could not write to Macintosh HD when I tried that once before, whereas now it can.

FMP is still not able to write to a folder inside my home folder. This is a problem. Let me take a second look at all the posts that followed my second-to-last post, to see if there's something that'll work - will get back.

[mathematrucker]

Yikes it was nothing more than a path syntax issue in FMP, leaving out the leading forward slash after "file:" How embarrassing.

Sorry about leading everyone down the wrong, well, better stay away from bad puns at this point.

-math