I have a very important file which an application in my workplace uses, i need to make sure it is not delete whatsoever, how can I do that?

  • 13
    Make a backup, so you can restore it ... Other than that, chattr +i might help but will make the file read-only as well (and can be overriden with chattr -i), also you can try to protected it with SELInux etc. – Sven Dec 2 '14 at 16:02
  • 43
    Can root create a process that even root can't kill? – Mark Gabriel Dec 3 '14 at 0:23
  • 4
    @MarkGabriel Yes. A fork bomb. :) – reirab Dec 4 '14 at 14:07
  • 4
    God, Root, what is difference? – Dan Neely Dec 4 '14 at 22:10
  • 8
    The HW Admin may come and remove the disk, shred it, burn the remnants and feed them to hoghs. Or, better, some C(++) programmer may induce some nasal demons. Whatever is important to you, back it up. Twice. – Pavel Dec 5 '14 at 11:50

Yes, you can change the attributes of the file to read-only.

The command is:

chattr +i filename

And to disable it:

chattr -i filename

From man chattr:

A file with the i attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

  • 11
    For the interested, the bsd equivalent is chflags schg – Andrew Domaszek Dec 2 '14 at 16:10
  • 85
    Do note that a user with root access can unset that flag and then delete the file. That is unlikely to happen by accident but it does not prorect against intentional deletion. – Grant Dec 2 '14 at 16:42
  • 6
    @Grant, not if the Securelevel is set high enough. The boot process sets the securelevel to 2 before the network is enabled, so resetting the flag requires local machine access (but this means that files used in the boot process before that time need to be immutable as well). – Simon Richter Dec 2 '14 at 17:38
  • 16
    @Grant If one wants to take it to extreme, you can't prevent that the partition is deleted or the disk is put into a furnace or protons decay in 10^30 years ... – Hagen von Eitzen Dec 2 '14 at 21:27
  • 2
    @Itai Ganot man I wish I had read it 4 days ago. I was a question in an examination I took =/ – vfbsilva Dec 3 '14 at 20:41

Burn it to a CD. Put the CD in a CD-ROM drive and access it from there.

  • 15
    +1 for thinking out of the box. And, afaik, it has also been used before in some circumstances (black-box cdrom drive with cd in it shipped to its destination). It may not be appropriate if someone is able to disconnect the drive, anyway. – Alex Mazzariol Dec 4 '14 at 16:49
  • 1
    K.I.S.S. I love it! +1 – MonkeyZeus Dec 4 '14 at 20:56
  • 2
    I think that's the correct answer to this question. Changing file attribute (chattr -i) can't prevent malicious actions. – Bruno von Paris Dec 5 '14 at 8:23
  • 7
    These day a full-size SD card in a built-in cardreader may be a better solution - lower power consumption, faster access in many cases and more durable in no-write use. – Chris H Dec 5 '14 at 9:53
  • 3
    @jpmc26 hence CD-ROM drive. Those are read/only. – Thorbjørn Ravn Andersen Dec 6 '14 at 9:17
  1. Create a file system image.
  2. Mount the image.
  3. Copy the file to the mounted image.
  4. Unmount the image and remount it as read-only.
  5. Now you can't delete it.


# dd if=/dev/zero of=readonly.img bs=1024 count=1024
# mkfs.ext2 readonly.img
# mkdir readonlyfolder
# mount readonly.img readonlyfolder/
# echo "can't delete this" > readonlyfolder/permanent.txt
# umount readonlyfolder
# mount -o ro readonly.img readonlyfolder
# cat readonlyfolder/permanent.txt 
can't delete this
# rm readonlyfolder/permanent.txt 
rm: cannot remove `readonlyfolder/permanent.txt': Read-only file system
  • 3
    mount -o remount,rw readonlyfolder/ && rm readonlyfolder/permanent.txt – Kaz Wolfe Dec 3 '14 at 23:08
  • 3
    Taking this a bit further, you can use squashfs or cramfs which are compressed and read-only. It needs a special tool to build the filesystem. – Zan Lynx Dec 5 '14 at 17:44

Linux has so-called bind-mount option which is rather powerful and useful feature to know:

%  cd $TMP && mkdir usebindmountluke && cd usebindmountluke
%  echo usebindmountluke > preciousfile
%  sudo mount -B preciousfile preciousfile
%  sudo mount -oremount,ro preciousfile
%  echo sowhat > preciousfile
zsh: read-only file system: preciousfile
%  rm preciousfile
rm: cannot remove ‘preciousfile’: Read-only file system

— what's being done here is bind-mount file to itself (yes, you can do that in Linux), then it's re-mounted in R/O-mode. Of course this can be done to directory as well.


You should create multiple hard links to the file as well. These should be in various locations that regular users can't access.

This way, even if they do manage to override your chattr protection, the data will remain and you can easily restore it where your application is looking for it.

  • 11
    Hard links won't protect the contents of the file. – 200_success Dec 3 '14 at 8:02
  • However they will provide additional protection from DELETION, which was the original question. – barbecue Dec 5 '14 at 20:28
  • 2
    @barbecue If the file is unlinked at the name an application looks for it at, it doesn't matter that the file's content exists under some other name. For anything looking for the file with the expected name, the file still has been deleted. – a CVn Dec 8 '14 at 12:36

Others have answered your question as you've asked it. As @Sven mentioned in a comment, the general solution to the question, "How do I make sure I never lose a file?" is to create a backup of the file. Make a copy of the file and store it in multiple places. In addition, if the file is extremely important and your company has a policy for backing up important data with a backup service, you might look into have this file included in the service.

  • 2
    Well, of course the file is being backed-up regularly, I just wanted another layer of protection against users which are sometimes working on the box with root user permissions. – user256033 Dec 3 '14 at 8:37

On Linux the immutable flag is only supported on some types of file system (most of the native ones like ext4, xfs, btrfs...)

On filesystems where it's not supported, another option is to bind-mount the file over itself in read-only mode. That has to be done in two steps:

mount --bind file file
mount -o remount,bind,ro file

That has to be done at each boot though, for instance via /etc/fstab.

  • I hope anybody umount the file to get write permissions again – whoan Oct 24 '17 at 3:18

In a comment to the answer by Kevin, Jerry mentions:

Well, of course the file is being backed-up regularly, I just wanted another layer of protection against users which are sometimes working on the box with root user permissions. –

I'm going to assume that you can't change this practice, as it's a really, really bad idea.

All of the suggestions about using a read-only device have the same problem -- it makes it a PITA for you to make legitimate changes when you need to. In the case of a lockable drive, such as an SD card, you run into the problem that you're suddenly vulnerable when you unlock it to make your changes.

What I would recommend instead is setting up another machine as an NFS server, and sharing the directory with the important files to the machine(s) that the users have root on. Share the mount as read-only, so that the machines with users you don't trust can't make any modifications. When you need to legitimately make changes, you can connect to the NFS server and make our changes there.

We use this for our webservers, so that a successful exploit against the webserver won't be able to insert or change any files that the server would then serve back out, or change the configuration.

Note that this can stull be bypassed in the same way that all of the mount-point related ones can be :

  • Make a copy of the protected directory
  • Unmount the directory
  • Move the copy in place of the mount, or symlink it in if that mount doesn't have sufficient space.
  • Why is it a "really, really bad idea" to back up an important file regularly and also make an effort to protect the original against accidental deletion? In the OP's original question, and from the OP's comment on the answer you referenced, it is clear that the concern is no malicious activity, but accidental/incompetent activity. – Craig Dec 7 '14 at 19:54
  • 1
    @Craig : it's a bad idea to have lots of users with root, especially if they aren't trusted to not mess with critical files. – Joe H. Dec 8 '14 at 7:36
  • Ah... well of course it is. :-) But that wasn't the crux of the OP's question. The OP asserted that there are users with root access who should be protected against accidentally deleting a file. – Craig Dec 8 '14 at 8:36
  • @Craig : it might not be the crux of the question, but it is the crux of the problem (XY problem?) ... but I have no idea what they're doing as root, so if they could make use of setuid and/or limited sudo privileges. And you should re-read the question, as I see no mention by Jerry that he's only trying to protect against unintentional removal ("i need to make sure it is not delete whatsoever"), and he only gave one follow-up that I see (which triggered my response). – Joe H. Dec 8 '14 at 8:46

Why not create an ISO 9660 image, which is read-only by design?

Mount the ISO image, and it'll look like a CD-ROM, but with the performance of a hard drive, and files on the mounted image will be just as safe from deletion as files on a physical CD-ROM.

The idea of burning the sensitive file to a CD and running it from a CD-ROM is interesting, assuming that setting the immutable bit on the file isn't deemed sufficient.

There are potential negative issues with running it off a physical CD, including performance (CD-ROM drives are much, much slower than hard drives or SSD's). There's the likelihood of the CD-ROM being removed by a well-meaning individual and replaced with a different disc that they need access to. There's the likelihood of a malicious party just taking the disc out and tossing it in a microwave (or the trash), thus "deleting" your file. There's the inconvenience of having to have a dedicated hardware CD-ROM drive just for that one file, and other factors.

But the OP made it clear that the primary intent is to protect against accidental deletion, not against malicious acts, and that the file(s) in question is backed up and recoverable should an accident occur, but it is highly desirable that the file never be accidentally deleted.

It seems that running the file from a mounted ISO image would satisfy the requirement.

  • 1
    Root can still delete a file by manipulating the image directly. It is just a normal file which happens to be mounted. – Thorbjørn Ravn Andersen Dec 9 '14 at 0:24
  • @ThorbjørnRavnAndersen How so? ISO 9660 by design is immutable. The party making that change would have to delete and replace the entire ISO file. Not that they couldn't do that. But they couldn't go in and surgically delete one file without tremendous expertise, if even then. It would be much easier to remove a physical CD-ROM from a drive and toss it in a dumpster. ;-) – Craig Dec 9 '14 at 0:29
  • No need to be sophisticated - just overwrite the image file with zeros. – Thorbjørn Ravn Andersen Dec 9 '14 at 0:51
  • @ThorbjørnRavnAndersen I'll concede that point easily enough. The caveat is that it would require intentionally dismounting the image and overwriting it. A thorough perp would just shred it at that point. But unless you are denying physical access to the machine, it still seems easier to just pop a physical CD out of the drive and toss it in the dumpster than to dismount and overwrite the ISO file, although either is easy. And the OP has stated that the important file is backed up on a regular basis, so this is just an extra measure against accidental damage, not against malicious mischief. – Craig Dec 9 '14 at 1:15
  • I've pointed out how to change an ISO9660 image even if it is supposed to be unchangeable. My point is that if a bit is writable at all, root can write it. – Thorbjørn Ravn Andersen Dec 9 '14 at 12:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy