Lion asking for password to delete trash or overwrite files

Wow, so many threads about permission problems and so many different answers. Thanks for these. I hope someone can eventually put a pointer in all the various threads to whichever solution actually works most comprehensively -- I can't tell the fixes from the workarounds and worry that trying one may screw up another.

But -- these look good.

I tried the restarting with cmd-R (Lion 10.7.1, mid-2011 Mini) -- but got an ordinary boot.

No "Repair Utilities" screen.

I don't see "Cmd-R" listed among the various boot key combinations.

Can anyone verify does booting into a "Repair Utilities" exist in Lion?

If so, how to get at it?

@MSiLight - great solution1 Fixed my problem perfectly. Many thanks.

🙂

Hello,

there are many different "solutions" mentioned which all did not solve the problems for many of us.

I now found the solution which solved my problems and it should solve your problems as well.

You start "Terminal"

1. Type: "ls -la"

A list with the current files in your home directory opens

2. Look for the line ending on .Trash: "drwx------ 2 root staff 68 14 Okt 13:48 .Trash"

If you see "root" or an other username than yours in that line, THAT is the problem.

3. Type: "sudo chown -R USERNAME .Trash/"

Of course change the USERNAME into your username

4. Check result by typing: "ls -la"

You should see this as a result: "drwx------ 2 USERNAME staff 68 14 Okt 13:48 .Trash"

Problem solved!

Thanks.

Are you logged in as Administrator?

I understand that files that will not delete, can best be done by temporarily turning on "secure delete" in Finder preferences.

Does this work if more than one user is working on that computer?

This is the real magic. I have several logins on my system and going through the GetInfo display allowed me to enable the primary login's account, but left the error for other logins. Grrrrrr.

I did see the password required to delete things problem but the big deal was that neither TextEdit or Preview would work, because of the error:

---------------------------------------------------------------------- Error below!----------------------------------------------

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)

Exception Codes: 0x0000000000000001, 0x0000000000000000

Application Specific Information:

dyld: launch, running initializers

/usr/lib/libSystem.B.dylib

xpchelper reply message validation: sandbox creation failed: 1002

Saving after update for container (~/Library/Containers/com.apple.TextEdit/Data) failed: NSCocoaErrorDomain:513 You don’t have permission to save the file “Container.plist” in the folder “com.apple.TextEdit”.

---------------------------------------------------------------------- Error above!----------------------------------------------

So I tried ls -le and of course I saw

:

drwxrwxrwx@ 46 tester staff 1564 Oct 14 16:17 Library

0: group:everyone deny delete

1: user:babbott allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextat tr,writeextattr,readsecurity

2: group:admin allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextat tr,writeextattr,readsecurity

drwxrwxrwx+ 5 tester staff 170 Sep 15 16:02 Movies

0: group:everyone deny delete

drwxrwxrwx+ 6 tester staff 204 Sep 15 16:02 Musi

And, it turns out, I had zillions of useless files with this sort of thing

-rw-rw-rw-+ 1 tester staff 4433 Aug 25 20:05 7e4edc06e818c9f05aeed8ec1a1cfbd030136168.xml

0: user:babbott allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity

1: group:admin allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity

-rw-rw-rw-+ 1 tester staff 4518 Aug 31 18:39 7e5e9b963704d7174fd4b3af2988310385d17957.xml

0: user:babbott allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity

1: group:admin allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity

-rw-rw-rw-+ 1 tester staff 4701 Aug 12 16:43 7e64fe4487a73cabb37de30e411b8ed5872c74fe.xml

0: user:babbott allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity

1: group:admin allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity

which I'd probably created by "Apply to enclosed items" from the Get Info panel. Live and learn.

So here we were:

prome-1n-dhcp171:~ tester$ ls -le /

total 30445

drwxrwxr-x+ 38 root admin 1292 Sep 30 13:59 Applications

0: group:everyone deny delete

drwxrwxr-x@ 16 root admin 544 Jul 8 13:18 Developer

drwxrwxrwx 2 root wheel 68 Jul 13 10:39 ISO-Images

drwxr-xr-x+ 60 root wheel 2040 Sep 30 16:12 Library

0: group:everyone deny delete

drwxr-xr-x@ 2 root wheel 68 Jun 18 12:44 Network

drwxr-xr-x+ 4 root wheel 136 Oct 5 13:08 System

0: group:everyone deny delete

drwxr-xr-x 8 root admin 272 Jul 27 19:18 Users

drwxrwxrwt@ 5 root admin 170 Oct 14 17:56 Volumes

0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

drwxr-xr-x@ 39 root wheel 1326 Oct 5 13:04 bin

lrwxr-xr-x@ 1 root wheel 11 Jul 27 19:11 etc -> private/etc

dr-xr-xr-x 2 root wheel 1 Oct 14 18:01 home

-rw-r--r--@ 1 root wheel 15565404 Aug 9 20:58 mach_kernel

etc:

And here's the solution, in my case:

prome-1n-dhcp171:~ tester$ chmod -a "group:everyone deny delete" /Library

chmod: Failed to set ACL on file '/Library': Operation not permitted

Ok...

prome-1n-dhcp171:~ tester$ sudo chmod -a "group:everyone deny delete" /Library

Ah...

prome-1n-dhcp171:~ tester$ ls -le /

total 30445

drwxrwxr-x+ 38 root admin 1292 Sep 30 13:59 Applications

0: group:everyone deny delete

drwxrwxr-x@ 16 root admin 544 Jul 8 13:18 Developer

drwxrwxrwx 2 root wheel 68 Jul 13 10:39 ISO-Images

drwxr-xr-x 60 root wheel 2040 Sep 30 16:12 Library <=== byebye all gone!

drwxr-xr-x@ 2 root wheel 68 Jun 18 12:44 Network

drwxr-xr-x+ 4 root wheel 136 Oct 5 13:08 System

0: group:everyone deny delete

drwxr-xr-x 8 root admin 272 Jul 27 19:18 Users

drwxrwxrwt@ 5 root admin 170 Oct 14 17:56 Volumes

0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

drwxr-xr-x@ 39 root wheel 1326 Oct 5 13:04 bin

lrwxr-xr-x@ 1 root wheel 11 Jul 27 19:11 etc -> private/etc

dr-xr-xr-x 2 root wheel 1 Oct 14 18:01 home

-rw-r--r--@ 1 root wheel 15565404 Aug 9 20:58 mach_kernel

and now, Ta Da! I can use TextEdit and Preview from this login. Nice!!

Bill

ckujau's response above,

"Re: Lion asking for password to delete trash or overwrite files

Aug 7, 2011 2:30 AM (in response to iVmichael)"

Is the most general and correct solution I have seen here. How do I vote for this to be a correct answer? Works on my multi-login herd... (2 iMacs, 2 MacBook Pros)

JoaoPepe wrote:

Try going to Disk Utility -> "select HD" -> First Aid -> Verify/Repair disk Permissions

I'm not sure exactly what ckujau did recommend? Remember this thread is read by a wide audience, not all highly computer literate like you people.🙂

My first line of attack would be running Repair Permissions in Disk Utility, which is quite a usual procedure after installing a large update.

I recommended to 1) find out what the problem was by running "ls -le". That way one can actually see why "Finder" or some other application cannot delete/write to a file and 2) to remediate the problem by fixing the permission of these "strange" files, making Lion asking for a password when one wants to delete a file.

Someone even followed this advice and succeeded :-)

I understand that not everybody is used to the commandline (and rightly so: it's not 1970 anymore) and this whole "chmod" business sounds weird. But while running the magically "Fix Permission" in DiskUtility may sound like a good start I'm kinda troubled that noone seems to care why this would or would not help at all or even suggest to install some magic software to make the trashbin work again.

Again: there's no magic involved here. Just weird permissions to be cleared up. And maybe a bug or two to be opened for a) some application setting these bits by accident and b) for poor user-experience in MacOS (The "Finder" could have just offered to repair these weird permissions and be done with it).

Lets not argue about this too much. I was looking for a generic solution, for dummies like me. I run DU Repair Permissions after an upgrade and do not have these problems. Maybe I'm just lucky.😎

Thank you ckjau.

I hope someone with Apple has filed a bug report and points to this answer when people ask the same question as there are quite a few threads open with the same kind of problem -- from folks who have already tried the obvious answers and for whom the obvious answer doesn't work.

Sure seems like it's a bug.

I hope someone with Apple has filed a bug report

http://www.apple.com/feedback/macosx.html

Try this out, worked for me, and it's easy as taking candy from a kid. Not that I did that. Anyway:

STEP 1. Make your hidden and system files visible:

Open Terminal.app and type: defaults write com.apple.Finder AppleShowAllFiles YES

STEP 2. In your home folder, look for the ".Trash" folder.STEP 3. Right click and select "Get Info".STEP 4. Look at the bottom of the recent opened window for Sharing & Permissions.*** STEP 5. THE PROBLEM ***

• You should see that there's two users: system and everyone.
• System is NOT you, there should have your user too.

STEP 6. Click the + (plus) sign and add your user (assuming you're the admin).STEP 7. Set Read & Write permissions for you.STEP 8. Click the lockpad again to lock it (duh :S).STEP 9. Make your hidden and system files INvisible again:

Open Terminal.app and type: defaults write com.apple.Finder AppleShowAllFiles NO

That worked for me. Cya!

very good. But even "taking candy from a kid" is too difficult sometimes: to avoid Terminal completely, you better install a simple widget called "hiddenfiles.wdg" to be able to choose see hidden files or not.