46

I get permission denied when trying to move folder Music via mv although directory owner is set to my user and user permissions are set to 7. What's going on?

(I know that I could use sudo but I want to find out what's wrong. Something smells fishy here). Ps: I am on Mac OS X El Capitan.

Terminal screenshot

Improve this question
1
  • 3
    Anyone stumbling upon the same error, it might be because you're trying to mv a file which is open. Not the OP case though, just saying so it might help.
    – aderchox
    Commented Dec 21, 2019 at 13:28

7 Answers 7

Reset to default
75

I was using Windows Subsystem for Linux. I had the directory open in a different bash instance. Closing it let me move the directory.

Improve this answer
3
  • 20
    In VS Code with remote on WSL I had to close editor and open up a terminal to WSL outside of that VS Code project.
    – Bjorn
    Commented Feb 19, 2020 at 1:58
  • this stems from the NTFS limitation that prevents renaming directories which have a handle open to anything below
    – netawater
    Commented Aug 3, 2020 at 5:42
  • 1
    For me it was a file explorer with the tree view (on the left) still open on the directory.
    – lolesque
    Commented Aug 25, 2021 at 9:50
28

Do note that, when in folder a, moving b to c, the folder permissions of a determine what you can do.

In this case, the permissions on . will be most important.

Observe that the permissions are more complex than simply rwx. Your music folder has an @ at the end, the . folder has a + at the end.

  • Use xattr -h to determine the complex permissions for the @ symbol.
  • Use getfacl to determine the ACL for the + symbol.
Improve this answer
8
  • Do you have a resource that covers "complex permissions", as you call them?
    – user1717828
    Commented Oct 6, 2015 at 13:39
  • man xattr might be a good starting point.
    – Konerak
    Commented Oct 6, 2015 at 13:51
  • 2
    nope, no manual entry. I was able to Google around to find another name for it: extended attributes, if anyone else wants to learn more.
    – user1717828
    Commented Oct 6, 2015 at 14:10
  • 4
    Or use ls -la@e. Most likely here, there was a deny delete ACLs that also prevents renaming.
    – Stéphane Chazelas
    Commented Oct 6, 2015 at 14:11
  • 1
    @Timo, those ACLs do prevent deleting or renaming those directories. Presumably, they were put there for a reason, like some applications rely on them being there and would fail otherwise.
    – Stéphane Chazelas
    Commented Oct 7, 2015 at 10:03
14

Seems like as if there was at least 1 file somewhere deep in that directory that didn't have right permissions.

So, what I did was:

sudo chown -R valmar ./Music
sudo chmod -R 755 ./Music

Now it works.

Improve this answer
7
  • 21
    Whatever the problem was, giving execute permissions to music files should not be the solution.
    – Stéphane Chazelas
    Commented Oct 6, 2015 at 16:01
  • 3
    And it seems unlikely that an object in a directory could interfere with your ability to rename that directory.
    – Scott - Слава Україні
    Commented Oct 6, 2015 at 18:35
  • I know it's weird but that did the trick. Using chmod and chown on the directory itself had no effect.
    – Timo Ernst
    Commented Oct 6, 2015 at 19:36
  • is it possible that chmod 755 removed the special '@' permissions on the Music folder?
    – HorusKol
    Commented Oct 7, 2015 at 3:15
  • 1
    Must be the additional x bits for group, etc...unix.stackexchange.com/questions/21251/…
    – HorusKol
    Commented Oct 7, 2015 at 21:41
9

The problem here likely has to do with the Access Control List (ACL) of the Music folder. The ACL is a separate permission system to the regular POSIX ones that are normally listed by ls -l. Some other directories in the Home folder and elsewhere also have ACLs.

Note, I'm referring to the macOS versions of the ls and chmod tools to view and modify ACLs below, since this question is tagged osx. Linux systems use getfacl and setfacl instead. I'm also using the full paths to the system ls and chmod executables, in case you have the Gnu versions installed, e.g. from Homebrew.

To see the ACLs within the home directory, use:

/bin/ls -le ~

You will likely see a rule like 0: group:everyone deny delete for the Music directory. As you noted you could override the problem with sudo. If you don't want to do that (or can't), you have other options, given that you're the owner of the file. You can strip off the offending entry from the Music directory's ACL, based on its index (0 in the example I gave above):

/bin/chmod -a# 0 Music

Or you can strip off all entries in the ACL:

/bin/chmod -N Music

Now you can move the directory around (subject to the regular POSIX permissions). If you want to put the ACL back after renaming the directory to Music_tmp, say, you could use:

/bin/chmod +a "group:everyone deny delete" Music_tmp

And use /bin/ls -le again to verify the ACL.

Check out the ACL examples in man chmod for more info. In particular, this intro is helpful:

Each file has one ACL, containing an ordered list of entries. Each entry refers to a user or group, and grants or denies a set of permissions. In cases where a user and a group exist with the same name, the user/group name can be prefixed with "user:" or "group:" in order to specify the type of name.

ACL Order

I don't think that man page explains the rules around ordering, but this page explains the order rules for ACLs clearly. In particular, an explicit deny rule will be applied before an explicit allow rule. So, as long as the group:everyone deny delete entry is in place, it's not possible to give your user permission to delete with an allow rule. This is because permission is denied to the everyone group, which includes you, and that rule will be applied first.

Improve this answer
2
  • 3
    I don’t know why this was downvoted. The everyone deny delete ACL entry on macOS’ default home directories is the actual reason the directories can neither be moved nor deleted. (Also, do note the OS might re-create them anytime.)
    – Diti
    Commented Feb 27, 2019 at 16:41
  • 2
    this answer ROCKED!!! holy crap, these new ACL's are a HUGE PITA.
    – Dean Hiller
    Commented Apr 11, 2019 at 23:25
3

I had this problem when a set of programs was running in a directory I was trying to remove. In order to move the directory, I had to first kill all running programs from that directory.

In the following commands, be very careful about how you select the name of your program. I used the following commands, for reference:

ps aux | grep -i [NAME_OF_ANNOYING_PROGRAM] | grep -v grep
# make sure that you are only about to kill the programs you want to kill

ps aux | grep -i [NAME_OF_ANNOYING_PROGRAM] | grep -v grep | awk '{print $2}' | sudo xargs kill -9
sudo mv /usr/local/[DIR_FOR_ANNOYING_PROGRAM] /usr/local/[DIR_FOR_ANNOYING_PROGRAM]2

The general procedure is:

  1. kill all programs running from the directory in question
  2. attempt to rename directory
  3. if that fails, force kill (kill -9 with a lot of caution) all programs from the directory
  4. attempt to rename directory
  5. if that fails, see if the program is running again, I.e. that it has been restarted by some daemon program running from a different directory
  6. force kill the daemon program that restarts the annoying program
  7. force kill the annoying program
  8. rename directory
  9. profit
Improve this answer
7
  • 1
    I don't think the OP likely has any programs running from the ~/Music directory. Anyway he said he doesn't want to use sudo, which this answer does.
    – SpinUp __ A Davis
    Commented Feb 27, 2019 at 2:16
  • All I'm saying is I had that situation. Might be helpful to someone even though it wasn't helpful to the OP.
    – WattsInABox
    Commented Mar 1, 2019 at 1:14
  • It's possibly helpful for someone, certainly -- that's why I didn't downvote. But I think the intention of StackExchange is that the posted answers actually answer the question that was asked.
    – SpinUp __ A Davis
    Commented Mar 1, 2019 at 18:22
  • 1
    Another potential issue, if you're meaning for this answer to be of general use to a novice: you don't provide any warnings about choosing your search terms very carefully in the first grep and checking it. Whatever you're putting in to that first grep will choose from the pool of all running programs and kill it with root privileges...
    – SpinUp __ A Davis
    Commented Mar 1, 2019 at 18:26
  • 1
    Nice, @Watts, I think that's a big improvement
    – SpinUp __ A Davis
    Commented Mar 1, 2019 at 19:58
0

That also can happen when one of the files inside is write-protected. I had the edge case today when access.log was write-protected to Apache, which was already stopped. I just removed this file, so further I was able to move parent directory.

Improve this answer
-2

I had same Issue. What helped was the Almighty sudo command. prepend that to your mv command and try again. That should work

sudo mv <old_name> <new_path>

Hope it works

Improve this answer
1
  • sure, sudo does the trick. assuming you are on your own mashine. in web developement, access rights aren't as easy, especially if you work as for external companies and only have access to the deployment pipeline
    – clockw0rk
    Commented Aug 18, 2022 at 14:53

You must log in to answer this question.

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