In some recent update, the finder has asked me for to enter my password before I can move a file to the trash. It's a similar issue to this question: Finder asks for password to move file to trash, except the OP's solution there did not work for me.

The annoying part about this is that I cannot delete files from my music player (Clementine) like I used to -- it just gives me an error, so I'm assuming it's related.

How can I fix this and revert it back to its original behavior of not needing to prompt every time I move a file to the trash?


Thanks to the comment below I have the following:

MacBook-Pro-8:~ shane$  ls -leO@d ~/.Trash ~/Music/Folder_1/ ~/Music/Folder_2/
drwx------    7 shane  staff  -  224 Sep  5 13:28 /Users/shane/.Trash
drwxrwxr-x@  22 shane  staff  -  704 Jun  2 08:22 /Users/shane/Music/Folder_1/
    com.apple.macl    72 
    com.apple.quarantine      57 
dr-xr-xr-x@ 116 shane  staff  - 3712 Sep  3 17:47 /Users/shane/Music/Folder_2/
    com.apple.macl    72 
    com.apple.quarantine      57 

So it turned out this prompt was only happening in one folder (Folder_2). Obviously it's missing write permissions. I'm just not sure how this happened as I followed the same process for this as the other 10 or so folders that don't have this problem (i.e. download playlist, extract it, move it to the Music directory) -- so something seems to have changed with the default permissions at some point in this process?

  • 1
    You'll have to do more troubleshooting to figure out what's causing the problem. Do you get prompted for a password for any file you try to throw out, or just some files? If you use the Finder to create a new (empty) folder on the Desktop, and then throw it out, does it prompt? If it does, open Terminal and run ls -leO@d ~/.Trash ~/Desktop, and edit the result into your question (as a code block so it's readable). As for the Clementine files, where are they, exactly how are you trying to delete them, and what's the exact error? Sep 3, 2021 at 23:11
  • @GordonDavisson good call on those troubleshooting steps -- I updated the question with some more info based on that
    – ShaneOH
    Sep 5, 2021 at 17:34

1 Answer 1


Troubleshooting: There are a wide variety of things that might cause a problem like this, so the first thing to do is to try to figure out what's causing it in your particular case. And a good first step in troubleshooting is to try to isolate the source of the problem by changing things, and seeing which affect the problem. For instance, does it happen with all files, or only some files (or files in certain folders, or on certain volumes, etc). Create files and/or folders in various places, and try throwing them out. If it happens with only certain files or folders or whatever, it's probably something about those particular files/folders, and you should concentrate on them; if it happens everywhere, it's more likely a general problem (e.g. something with your .Trash folder.)

(Note: macOS keeps a separate trash folder on each volume -- because you can't put a file that's physically on one volume into a folder (including a trash folder) on a different volume. On the volume where your home folder is, it's ~/.Trash; on other volumes, it's /Volumes/volumename/.Trashes/$UID, where $UID is your user ID number, usually 501.)

Once you've got an idea where the problem's coming from, you can get more info about file/folder permissions with ls -leO@ (or ls -leO@d to see a folder's permissions, rather than its contents). Here's an example on my Mac:

$ ls -leO@d ~/.Trash ~/Desktop
drwx------  75 gordon  staff  - 2550 Sep  5 02:03 /Users/gordon/.Trash
drwx------@ 62 gordon  staff  - 2108 Aug 31 00:59 /Users/gordon/Desktop
    com.apple.FinderInfo      32 
 0: group:everyone deny delete

I won't go into detail here, but the rwx------ bit is the regular unix permissions; gordon staff is the owner and group; the - after that is flags (- means none; uchg means it's locked) the com.apple.FinderInfo line is an extended attribute, and the 0: group:everyone deny delete is an access control entry.

(The deny delete access control is normal here, it's just to keep people from deleting their Desktop folder by mistake. It only applies to the Desktop folder itself, not its contents. Well, unless it had an inherit attribute, but it doesn't.)

In this case, it looks like the permissions are messed up on a specific folder:

dr-xr-xr-x@ 116 shane  staff  - 3712 Sep  3 17:47 /Users/shane/Music/Folder_2/
    com.apple.macl    72 
    com.apple.quarantine      57 

That dr-x at the beginning means it's a directory (aka folder), and the owner (shane) has Read and eXecute (actually search... long story) permissions, but not Write. Write access on a folder controls making changes to its contents: creating/moving files, renaming files, and deleting files. You should almost always have write access to your own stuff.

Fortunately, it's easy to add write access:

chmod u+w /Users/shane/Music/Folder_2/

The u+w bit here means "for the user (i.e. the owner), add write access".

I have no idea what would've caused those weird permissions in the first place, but hopefully that's the only problem and this'll solve it.

  • I really have no idea what caused the permissions discrepancy originally, since I created this folder like I had all the others -- but this explanation was great and changing the permissions as described completely solved the problem, including deleting from the app. Thanks so much for your time and effort!
    – ShaneOH
    Sep 20, 2021 at 19:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .