Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

nasty little permissions loop - assistance requested

hi all,


got a strange little problem here that is totally got me stumped. we had an older xserve die on us recently, a g5 system running 10.5. we were able to recover most of the file content we needed off of the server, but not all of it (yet), and not any of the system files itself (the main drive was toast)


the problem im having is this... we've been migrating this content over to a newer server running 10.6.8 server. Several of the files we need to get at and modify however were locked via the finder right before the original server went down (we do this to prevent others from editing a live file on the server). now, because the user data for these files was lost (terminal & finder show them as being owned by "unknown") we cannot change ownership of the files to unlock them.


so basically, its a permissions loop that we cannot escape from:


terminal will not let us chown or chmod the file, because its owner is unknown

because the file is locked via finder, it will not let us change the owner.


content2:~ hrexroad$ sudo chmod 777 /Volumes/VAULT/content1backup/docs/parks/interviews/IMG_6151.mov

chmod: Unable to change file mode on /Volumes/VAULT/content1backup/docs/parks/interviews/IMG_6151.mov: operation not permitted


content2:~ hrexroad$ sudo chflags nouchg /Volumes/VAULT/content1backup/docs/parks/interviews/IMG_6151.mov

chflags: /Volumes/VAULT/content1backup/docs/parks/interviews/IMG_6151.mov: permission denied


content2:~ hrexroad$ sudo chown hrexroad /Volumes/VAULT/content1backup/docs/parks/interviews/IMG_6151.mov

chown: Unable to change file mode on /Volumes/VAULT/content1backup/docs/parks/interviews/IMG_6151.mov: operation not permitted



wondering if anyone has any tips on how we can get out of this. copying the file does nothing; it comes back with not having permission to read it. we're really stuck on this; any help would be greatly appreciated.

Posted on May 19, 2012 12:42 PM

Reply
6 replies

May 19, 2012 2:32 PM in response to MrHoffman

here's the output i get from the affected directory:

content02:~ hrexroad$ ls -ale@ /Volumes/VAULT/content1backup/docs/parks/interviews total 55170112 drwx---rwx+ 11 hrexroad staff 374 May 19 14:15 . 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity drwx---rwx+ 36 hrexroad staff 1224 Dec 18 19:34 .. 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity -rw----rw-@ 1 hrexroad staff 6148 May 19 14:14 .DS_Store com.apple.FinderInfo 32 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity -rw----rw-+ 1 1000 staff 135626752 Feb 26 2012 IMG_5784.mov 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity -rwx--xrwx+ 1 1000 staff 2832226304 Mar 15 2012 IMG_5993.mov 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity -rw----rw-+ 1 1000 staff 1450901504 Mar 18 2012 IMG_6143.mov 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity -rw----rw-+ 1 1000 staff 2786361344 Mar 18 2012 IMG_6151.mov 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity -rw----rw-+ 1 1000 staff 6899996456 Mar 25 2012 IMG_6209.mov 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity drwx---rwx+ 6 hrexroad staff 204 Dec 19 2010 Scratch Edits 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity -rwx--xrwx+ 1 hrexroad staff 7016108704 Feb 16 2012 martin_welch_interview.mp4 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity -rw----rw-+ 1 hrexroad staff 7125860108 Feb 12 2012 martin_welch_interview_raw.mp4 0: 94CD0AB4-131E-4AD3-8856-3EA48D12025B allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity

May 19, 2012 3:10 PM in response to Henry Rexroad

Ah ha! I got it figured out. I was able to resolve this by backing all the way out to the storage array that everything is currently saved on. Going into the info for the raid disk itself, and checking on "ignore ownership on this volume" I was able to change the owner of the file to myself off of "unknown" user.


Thanks for your help Mr Hoffman!

May 20, 2012 7:42 AM in response to Henry Rexroad

It's feasible to remove the access control list entry and related baggage, rather than disabling the enforcement of those settings at the file server.


The usual command here is chmod, and (to clean off the ACLs, the chmod -N command.


To reset the owner and group, the chown command works nicely. chown user:group (with or without -R)


And FWIW, that 777 stuff is old-school Unix; I find the slightly newer syntax (ugo+rwx or a+rwx or a=rwx) is much easier to grok. These settings if you're going to allow everyone full write access to the files, of course.


Remember to check the ownership, protection masks and ACLs all the way up the directory hierarchy, as well. And use the -R switch to change settings recursively.

nasty little permissions loop - assistance requested

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.