Okay, I've been browsing various man pages and websites and cannot find an answer to this question (well, at least not one that is satisfactory for my needs).

Here's my situation:

I have a folder that files move in and out of on a regular basis via automation. The other day, someone was able to move some of these folders into another location, which, pretty much, broke my automated processes.

I want to stop that from ever happening again. I looked into the immutable attribute, but soon discovered that this option renders the folder nonoperational for my needs (I still need to be able to write to and remove files from the directory).

The sticky bit, also doesn't appear to be a viable option as who moved the folder was logged in as the folder's owner.

So there's the question: how do you make a folder un-deletable and immovable while still allowing read/write access to the files within the directory?

I turn it over to the community to see how this can be done. Thank you for any and all pointers.

Deny write access to the parent directory of that directory. Deleting a file performs a write operation on the directory containing the file. In this case, the file entry is a directory. Either deny write access to the parent directory or set the stick bit.

If might be better if the directory wasn't in a publicly accessible directory. For example, if it is reachable from a share, perhaps it should be shared on its own.

you can add an immutable flag to the directory

chattr +i <dir>

someone as root would have to do a chattr -i <dir> to be able to move it.

and ls -l** does not show the immutable flag

you could view the flags with lsattr

if you really wanted rename chattr to something weird that only you would know and then do a <whatever you named it> +i <dir>

tho i would recommend leaving it as chattr because alot of people have no clue what it is or does and they would have to be root or whoever owns the file to remove the flag so it can be moved or deleted


NOTE: setting the flag on a file will deny any write ability to that file

See, here's where we reach a problem:

The automated process moves files in and out of these directories and staff goes through the directories periodically to remove files that didn't get moved.

the chattr doesn't work because files cannot be created/deleted as needed.

another issue is that, the issue that caused to me to look into this a little, the user who had moved the directory was logged in as that directory's owner, so the sticky bit wouldn't help (as best I know, anyway).

anything else?

I think jschiwal's answer solves your problem.

In this example, "bar" represents your users' work directory. It would help if "bar"'s owner was not also an owner of "foo" (so that he couldn't add write permissions back).

If this will not work, please clearly explain why not.

Okay, this server sits between two different systems in different locations (kind of a DMZ on a private network, if you will). Let's call this server B. So, box C sends files to server B who turns around and passes it onto server A. This is a gross over simplification, but is about as detailed as I can get right now.

Now, the directories in question are the drop points for this process. They get dumped into these directories and are taken from these directories with a few moments of them actually being on server B.

The other day, someone removed a couple of these critical directories to another place on the box, causing automation to not be able to drop the files in the correct location (as they weren't there to dump into).

So, the issue is that I need to make it so that nobody can move or delete these directories, but not have that effect on the files under them.

Here's an example from me removing the write permissions on the test folder:

As you can see, this example doesn't permit writing to the directory, which is a must in this case. The chattr command is similar, and the problem with the sticky bit is that the user who moved the directory was the owner, so that isn't enough.

Hope this sheds enough light on this. Let me know, please.

My first recommendation is if you have foo/bar/files, that foo not be writable. You can still save files in /foo/bar/. If you don't want /bar to be deletable with the sticky bit set, make the owner root so a regular user can't delete it. Look at the /tmp/ directory as a model. / is only root writable. /tmp has full write permissions, but no regular user can delete the /tmp directory because the parent directory isn't writable by normal users. The sticky bit on /tmp protects the contents from deletion from other users.

It would be better to have a bar/ share so that users don't access foo at all. If you have /foo/bar and /foo/bar2, you can have a bar/ and a bar2 share.

It might be smart to have some checks in your scripts to see if the directories exists, just in case. You can have it re-create them if they're not there. Keep It Simple Stupid