Let's say user has Directory1 and it contains File1 File2 CantBeDeletedFile
How to make so the user would never be allowed to delete the CantBeDeletedFile?

If I change the ownership of Directory1 and remove write permissions users wouldn't be able to delete any file. They also wouldn't be able to add new files etc.

I just want to be able to set some files which would never be deleted.

More specific description.

I am creating user profiles. I am creating application launcher files in their Desktop. So I want to set some launcher files (.desktop) and make them so user can only launch them and they couldn't rename nor delete, just launch.

Currently if user owns the directory which contain any file. He can delete.

3 Answers
3

(I dislike intruding users' home, I think they should be allowed to do whatever they want to do with they homes… but anyway…)

This should work on linux (at least). I'm assuming user is already a member of the group user.
A solution is to change ownership of Directory1 and set the sticky bit on the directory:

chown root:user Directory1
chmod 1775 Directory1

Then use:

chown root Directory1/CantBeDeletedFile

Now, user won't be able to remove this file due to the sticky bit¹. The user is still able to add/remove their own files in Directory1. But notice that they won't be able to delete Directory1 because it will never be emptied.

—
1. When the sticky bit is enabled on a directory, users (other than the owner) can only remove their own files inside a directory. This is used on directories like /tmp whose permissions are 1777=rwxrwxrwt.

I dislike too, but users are newbies to the Linux world. IF they delete a launcher coincidentally they are starting to spam our tech support :)
–
bakytnSep 5 '11 at 7:30

Thank it works! Not sure how will I proceed. With chattr or by this way. If do on your way. I still can delete the Directory as a root. With upper solution (chattr) even root can't delete the folder.
–
bakytnSep 5 '11 at 7:39

@bakytn: is this just a precaution or have you actually gotten the support call? Because most newbies probably will be too scared to mess with files they don't know.
–
Lie RyanSep 6 '11 at 5:08

@Lie Ryan 100% sure that they would call for support. But yes, currently it's just a precaution.
–
bakytnSep 8 '11 at 18:40

Sooner or later the training wheels have to come off... and if they haven't learned to ride the bike the accident will be something to behold. I agree with the answer, probably supplemented withcopious on-line help and canned spam "If you 'accidentally' deleted ThisDesktopFile, first go to the nearest wall and bang your head hard against it 3 times (for luck), and then do cp /here/is/the/master/ThisDesktopFile $HOME. Signed: BOfH"
–
vonbrandJan 24 '13 at 0:39

I add this note as I was unable to deduce it from the mentioned man page: chattr only works on ext2/ext3/ext4 filesystems.
–
manatworkSep 5 '11 at 7:17

This is so cool! It worked! Thank you sir! Elegant solution, but one limitation. Even root can't delete those files without first making it mutable. But this is so cool actually. Wasn't sure which answer to accept. Accepted more generic way but less fast
–
bakytnSep 5 '11 at 7:42

Thank you for the advice, works great (SuSe)
–
KonstantinJun 4 at 13:26

I don't think there is a way to prevent deletion of an individual file with Unix file permissions, but I can think of a workaround: write a daemon that replaces it when it is removed. inotify-tools is perfect for this sort of thing if you're on Linux.

There are a few ways you can replace the deleted item: copy a new one in place, or keep the real file in a safe place and just copy a link into the user's directory. For the link, you can either use a symlink or a hard link. I'd start with a symlink, but some (very few) programs don't handle symlinks correctly. If you find that the user encounters a program like this, use a hard link instead.