Double Permissions on User folder means having to authorise to delete

[xUKHCx]

edit: Basically this is an issue with ACLs and having the + sign on the end of the folders permissions. Read down for the solution.

____


Something has gone a miss on my computer and has led to a weird situation where on a large number of folders the user permissions are doubled



As you can see from the picture above, I have full access to the folders and appear twice. I can not delete either of those entires from the list.

When I try and delete such folders it asks for my admin password. If I try and move the folder it copies rather than moves it.

No files I have come across at this stage have the same odd permissions.

 

[firestarter]

Yuck.

What do you get if you open a terminal window and type:

ls -ald <directory name>

(just pull the directory onto the terminal window to get the terminal name)

now try:

ls -aldn <directory name>

I think it's something screwy to do with modified group ownership - and this will show what the group settings are on an example directory.

Type 'whoami' in the terminal and you'll get your Unix name 'xxxx'

Now type

dscl . -read /Users/xxxx

Look for your 'UniqueID' and 'PrimaryGroupID'. What are they?

 

[synth3tik]

I wonder if that is like when the menu bar items get doubled up and one would have to repair disk permissions to fix the issue. I would hope it would be that easy.

On a similar note, when I recently restored my hard drive from my TM, all my TM folders had "unknown" as the owner. To fix the problem I had to 'get info' on every folder add me to the list and give myself (admin) read/write access. Still even after that I was unable to get rid of "unknown".

 

[firestarter]

I wonder if that is like when the menu bar items get doubled up and one would have to repair disk permissions to fix the issue. I would hope it would be that easy.

On a similar note, when I recently restored my hard drive from my TM, all my TM folders had "unknown" as the owner. To fix the problem I had to 'get info' on every folder add me to the list and give myself (admin) read/write access. Still even after that I was unable to get rid of "unknown".

If you're comfortable with Unix, using 'find' and 'chown' will fix this for you.

If not, SuperGetInfo will let you change the Unix user and group ownership recursively for a hierarchy of folders/files:

http://www.barebones.com/products/super/

 

[xUKHCx]

Yuck.

What do you get if you open a terminal window and type:

ls -ald <directory name>

drwxr-xr-x+ 94 rich staff 3196 21 Jul 17:39 Photos

now try:

ls -aldn <directory name>

drwxr-xr-x+ 94 501 20 3196 21 Jul 17:39

Type 'whoami' in the terminal and you'll get your Unix name 'xxxx'

Now type

dscl . -read /Users/xxxx

Look for your 'UniqueID' and 'PrimaryGroupID'. What are they?

UniqueID: 501
PrimaryGroupID: 20

 

[firestarter]

Is this your own machine, or a work one?

The OSX default is for your user and group to be 501, 501 and your user and group to both be the same (ie rich, rich). It's odd that you're defaulted to group 'staff'.

If you type:

ls -al <filename>

(Using a test file in one of these directories, which you have no trouble deleting) is it also rich, staff - or is it rich, rich?

What is the directory above these directories you're having problems with? Can you do an 'ls -ald' on that?

It could be that you don't have write access to the directory enclosing these, which is why you can't delete them.

 

[xUKHCx]

Is this your own machine, or a work one?

It is my machine.

If you type:

ls -al <filename>

-rw-r--r-- 1 rich staff 272931 19 Jul 15:48

What is the directory above these directories you're having problems with? Can you do an 'ls -ald' on that?

drwxr-xr-x+ 142 rich staff 4828 2 Jan 17:18

And the folder above that is

drwxr-xr-x 11 rich staff 374 2 Jan 16:27

Thanks for any insight that you can give.

 

[firestarter]

Well, although I'm a bit surprised at the rich, staff thing - this owner and group is at least consistent across all your files/directories - and it's also your default group, so that shouldn't cause any problems.

The r/w permissions seem correct on everything. The directory above these ones also allows you to have read/write/execute and has the same user/group.

You should be fine with the permissions as is.

Although I'm embarassed 'cos it seems like half-arsed advice, I would repair disk permissions, reboot and have another go. My top guess would be that Finder has got it's directory services in a twist - certainly there's nothing else that jumps out as being wrong.

 

[xUKHCx]

I had tried that previously. Just did it again to no avail.

It is odd because it affects random folders.

For example two folders next to each other



With the following output from ls -ald for both of them respectively

drwxr-xr-x+ 33 rich staff 1122 29 Sep 2007
drwxr-xr-x 6 rich staff 204 2 Mar 2008

 

[firestarter]

Well, this is interesting:

http://ask.metafilter.com/91968/OS-X-file-permissions-issue

Apparently the '+' on the end of the permissions string for some of your directories is showing that there are some extra permissions going on over and above the usual Unix permissons.

You can use ls -alde to reveal what those extended permissions are.

I haven't heard of this before... I'm a Unix guy - but mainly Sun/Solaris stuff.

 

[mkrishnan]

Well, this is interesting:

I noticed that right away, above, also, and I've never seen it before either.

So someone created the group "staff," correct, and placed you in it? And has your Mac been set up so that ownership of newly created files and directories is always rich:staff (instead of rich:rich), or at some point were these files given to the group staff manually? I wonder if this is happening because your group has a lower right (read only) to the file than you do (r/w)?

 

[xUKHCx]

Well, this is interesting:

http://ask.metafilter.com/91968/OS-X-file-permissions-issue

Apparently the '+' on the end of the permissions string for some of your directories is showing that there are some extra permissions going on over and above the usual Unix permissons.

You can use ls -alde to reveal what those extended permissions are.

I haven't heard of this before... I'm a Unix guy - but mainly Sun/Solaris stuff.

I think we (as in you) are getting somewhere.

For the same two folders above I get these outputs


drwxr-xr-x+ 33 rich staff 1122 29 Sep 2007
0: group:everyone deny delete
1: user:rich allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity

drwxr-xr-x 6 rich staff 204 2 Mar 2008

So that extra + is what is causing the problems.

I noticed that right away, above, also, and I've never seen it before either.

So someone created the group "staff," correct, and placed you in it? And has your Mac been set up so that ownership of newly created files and directories is always rich:staff (instead of rich:rich), or at some point were these files given to the group staff manually? I wonder if this is happening because your group has a lower right (read only) to the file than you do (r/w)?

Sorry you are talking a bit above my level. This is my computer and only I have ever done anything with it (unless the cats did something while I was not looking). It had a clean install of Leopard 10.5.0 on it and has the latest 10.5.6 update.

When I create new files they have rich:staff

One odd (probably unrelated but mihgt be related thing) is that my computer has started creating files such as this

/private/var/audit/20090102201054.not_terminated

I have no idea why.

 

[mkrishnan]

Yeah, based on what you printed above, I feel even more strongly that this has to do with your ACL and your group "staff."

Hmmm, okay, if you have no memory of having created the staff... well, you did it at some point. Normally if you just install OS X and create a single user, those files would have the two ownership blanks say rich:rich -- that is, you would be the user and the group.

What is going on here is that at some point, you created a group called "staff." The purpose of this group, ostensibly, would be so that other members of "staff" could read rich's files (but not write to them), whereas normally other users would have no permissions to your files.

There are a few ways you could fix this... obviously, you could get rid of "staff" altogether if you are unaware of why you have it (unless something you're using forces you to have it?). Or you could probably upgrade staff's privileges. Although, honestly, the concept above makes sense -- to have a group that can read but not write your files. I don't see why it should cause you this problem.

 

[firestarter]

For what it's worth, I don't have any '+' entries on my directories.

Reading the manual on chmod ('man chmod' at the command line) reveals the wonderful world of ACL - extended attributes for the file.

If you want to give it a go, the following should knock the ACL records (and the '+') off a directory:

chmod -N <directory or file name>

(if you don't have the right permission, try sudo chmod instead - you'll be asked for your admin password)

 

[xUKHCx]

obviously, you could get rid of "staff" altogether if you are unaware of why you have it

How would I go about doing that

If you want to give it a go, the following should knock the ACL records (and the '+') off a directory:

chmod -N <directory or file name>

Doing this on the folder worked

Is there anyway I can search for folders that have the ACL record on it or is it just a case of stumbling across the folders.

 

[mkrishnan]

Eeep, hold on, before you change anything, this lengthy thread might be worth reading...

http://discussions.apple.com/thread.jspa?threadID=1216618

Apparently the "staff" thing is new with Leopard (sorry, that's why it seemed off to me; I have not used Leopard much). Apparently, this may have to do with migration of an account from pre-Leopard (where you would have been rich:rich) to Leopard (where you are rich:staff), which Leopard did incorrectly. So if I understand this correctly, you are experiencing oddity because some files were migrated and their ownership / permissions were modified by Leopard, whereas others were created in Leopard after you had finished installation.

 

[firestarter]

Doing this on the folder worked

Is there anyway I can search for folders that have the ACL record on it or is it just a case of stumbling across the folders.

Unfortunately OSX's version of 'find' doesn't appear to have been modified to search for ACL tags (this would be my weapon of choice on a 'seek and destroy' mission).

You could just use a wildcard to modify everything.

Personally I think either of the above might be a tad dangerous. I'd be inclined to 'ls -al' in your home directory to see what's up, correct the ones you see with a '+' and leave it be.

 

[xUKHCx]

Eeep, hold on, before you change anything, this lengthy thread might be worth reading...

http://discussions.apple.com/thread.jspa?threadID=1216618

Apparently the "staff" thing is new with Leopard (sorry, that's why it seemed off to me; I have not used Leopard much). Apparently, this may have to do with migration of an account from pre-Leopard (where you would have been rich:rich) to Leopard (where you are rich:staff), which Leopard did incorrectly. So if I understand this correctly, you are experiencing oddity because some files were migrated and their ownership / permissions were modified by Leopard, whereas others were created in Leopard after you had finished installation.

In the process of reading that and trying to work out what it actually means for me. I think it means that the staff thing is alright.

Unfortunately OSX's version of 'find' doesn't appear to have been modified to search for ACL tags (this would be my weapon of choice on a 'seek and destroy' mission).

You could just use a wildcard to modify everything.

Personally I think either of the above might be a tad dangerous. I'd be inclined to 'ls -al' in your home directory to see what's up, correct the ones you see with a '+' and leave it be.

Thats good enough for me, shouldn't take too long to sort out for my home directories.

There are also entires with

drwxr-xr-x@

drwxr-xr-x@ 4 rich staff 136 20 Jul 13:17
0: group:everyone deny delete
1: user:rich allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity

These seem to be problem folders as well and the chmod -N command doesn't get rid of it.



(Side Thought, I wonder why this started happening today, all I have done differently is move my computer to a different house, perhaps something went iffy a little while ago and the reboot caused it to rear its head).

 

[firestarter]

These seem to be problem folders as well and the chmod -N command doesn't get rid of it.

Hmm. Don't know about those. Apparently they have extended attributes, not just extended permissions.

Perhaps -N knocks off the permissions fixing the problem, but leaves extra attributes and the '@'?

(Side Thought, I wonder why this started happening today, all I have done differently is move my computer to a different house, perhaps something went iffy a little while ago and the reboot caused it to rear its head).

Probably. The most evil and insidious computer problems lurk for weeks/months waiting for a reboot. By the time you discover the problem, there's no way you'll identify what originally caused them.

 

[xUKHCx]

There were a total of 36 folders in my home directory (didn't look too deeply in ~/Library).

The @ sign isn't necessarily a bad thing. I think that the folder I referred too above had something quite wrong with it and just happened to be the first one with an @ sign I saw. When browsing through my folders there were lots of @ signs.

All seems to be working correctly and fine for now. Touch wood.

A massive thanks to you both. I am glad that it was relatively easy to sort out (once the issue was found).