sudo chattr +i -f Adu1.tar
This fails and shows no message.
The file is on a second drive.
/media/andy/Maxtor/Backup/Ubuntu_Mate_24.04$ lsattr
lsattr: Operation not supported While reading flags on ./Engine_Cleaning_Material.tar
1 Like
Could it be the file is already set to the immutable characteristics? What does lsattr Adu1.tar show?
1 Like
I tried it with a file on my main drive.
~/bin$ sudo chattr +i Blank.sh
~/bin$ lsattr Blank.sh
----i---------e------- Blank.sh
It works.
The problem is that chattr is not working on the second drive ?
/media/andy/Maxtor/Backup/Ubuntu_Mate_20.04$ sudo chattr +i My_Sounds.tar
chattr: Operation not supported while reading flags on My_Sounds.tar
1 Like
There are a number of reasons chattr may not work. If the external disk doesn't support extended attributes, or if you don't have the permissions to change them. The file system on your external drive may not be supported by chattr.
Out of curiosity, what are you trying to make the file "untouchable" by even root? Can't you just set owner-group-world permissions on it? If you're the owner, you could simply run
chmod 0700 Adu1.tar
Which will make it visible only to you. If you want to make so that not even you can change it, just change the 0700 to 0400.
3 Likes
I managed to delete all my documents.
I want it so it "takes more work" to delete it. 
2 Likes
You don't need to use chattr. The permissions answer I gave you would work as well. In fact, if you changed the file permissions to 0000, even you can't read them. And if you try to delete them, you will be asked to override the permissions (answering 'n' is all you need to do to not accidentally delete them.
You could go one step further and create a non-login user account and change the ownership of your files to that account. Let's say you want to create such an account and call it protect. You could do the following:
adduser -r protect -- creates the account without a home directory AND a group for it
usermod -s /bin/false protect - prevent the account from having a shell
chown -R protect:protect /targetdir - assigns the ownership of the directory and its subdirectories to 'protect'
If you cat /etc/group you'll see some of the non-login groups. Consider them "system" groups, since they are used pretty much only for daemon processes.
Read:
man adduser
man usermod
man chown
2 Likes
To add to what Fred has already proposed as the ideal setup, you need to ensure that the privs for "protect" files are 644 (namely read-only to any user not part of the "protect" group), and that you only perform actions with a non-privileged user, i.e. your login account without root privileges. That way, normal Linux protections will be applicable. You may wish to create a small script-based menu interface for moving files into that "vault" or for removing any file. It is suggested that the removals option should prompt on a file by file basis, with no ability to use wildcarding (regex) to affect multiple files without knowing which specific ones are being affected.
Naturally, if you bypass that group restriction and do stuff using the sudo command or as root, all bets are off! 
2 Likes