Take the 2-minute tour ×

If a directory "foo" is owned by user A and contains a directory "bar", which is owned by root, user A can simply remove it with rmdir, which is logical, because "foo" is writable by user A.

But if the directory "bar" contains another root-owned file, the directory can't be removed, because files in it must be removed first, so it becomes empty. But "bar" itself is not writable, so it's not possible to remove files in it.

Is there a way around it? Or, convince me otherwise why it's necessary.

share|improve this question

2 Answers 2

up vote 7 down vote accepted

Interpretation 1: a directory is a subspace of the filesystem. It can be further subdivided into subsubspaces by creating subdirectories in it. The owner of the directory foo should have control over everything inside the subspace: foo/bar, foo/bar/qux, etc.

Interpretation 2: a directory is a subspace of the filesystem. Every directory is attached to some other directory, called its parent. The owner of the directory foo has control over everything inside the subspace; however, for a subdirectory foo/bar, the owner of foo has control over whether bar can be attached to foo but not over what goes inside bar: only the owner of bar has control over that.

Evidence in favor of interpretation 2: as you've noted, the way permissions work. Also, the fact that some Unix filesystems allow a directory to be attached to more than one parent: this is called having multiple hard links. (Having multiple hard links is common for regular files, but it's usually discouraged or forbidden for directories mainly because of the risk of creating loops, where a directory is its own grandparent N times removed — so you can't get to it from the root directory, which is a very common expectation. There's also the problem of what to do if a directory has 0 hard links but is not empty: since the directory is unattached, you'd want to delete it, but what do you do with its contents?)

Evidence in favor of interpretation 1: in practice, directories do have a single parent and so form a tree structure. And you can't access foo/bar/qux unless you have execute permission on foo as well as bar (well, except that there are somewhat obscure ways to be given access to bar without being given access to foo). So the upper levels do matter.

On a more practical note, in your situation, user A can do

mkdir garbage
mv foo/bar garbage/
rmdir foo
share|improve this answer
This is a great answer (rec'ed), but the apparent inconsistency remains frustrating to me. And while the practical example of moving bar to garbage does work, we're left with a directory called garbage that can't be removed. I've got this same issue, except that it's user A and user B, where B stuck something in a directory owned by A, which A wants to remove. –  Paul Hooper Aug 17 '10 at 16:27

The only way around this would be to use either a setgid or setuid on the parent directory or use an ACL.

Set the directory setgid with

chmod g+s foo

Set a default ACL on it with

setfacl -d -R -m g:group:rwx foo

This sets it as the default ACL on this path. You must mount the filesystem that contains this path with the acl option!

Now tell me why you think you want this.

share|improve this answer
Well, the problem is one of consistency. Nothing stops me from deleting a file or an empty directory owned by another user in a directory I own, but if it's not empty, I'm locked out from deleting my own directory. –  Alex B Jun 11 '10 at 8:33
If that's the case, I'd use one of the options I supplied. They'll work fine for you. –  wzzrd Jun 11 '10 at 9:08
I often use multiple accounts on my desktop (one of which is "main non-root" account). I can also get such situation when make install started from root starts building something. –  Vi. Jun 14 '10 at 13:48
setgid on the parent directory doesn't help. After done as root cd ~user && mkdir qqq && touch qqq/qqq I can't get rid of qqq from user by chmod g+s . and rm -Rf qqq. –  Vi. Jun 14 '10 at 13:54
Mmh. That's probably a umask matter then. If your directory is 775, it's setgid and your umask is 0002, then files are writable for group and therefore removable for you. But, true, it does not work with umask 0022 (which is mostly the default). Should have said that. Have you tested the acl option? –  wzzrd Jun 14 '10 at 14:01

Your Answer


