-2

I am trying to make a folder and its file read only so I do not accidentally delete it.

I have run

chmod -R 444 myfolder/

but when I then right click on the folderand go Properties>Permissions, it is still showing as read and write. I also tested by modifying a file, and the modification succeeds.

In addition, when I try to change the permission in the filemanager gui to read only, it immediately flips back to read and write.

I am under the impression that 4 means read only access. Is this correct?

EDIT:

I think my issue has to do with how the drive is mounted. Here is the fstab entry.

UUID=6F7C5E910607D747 /media/storage1 ntfs-3g uid=1000,gid=1000,umask=0022,auto,rw 0 0
  • updated post to answer your question. – ScottF Oct 21 '17 at 6:17
  • 2
    Are you using root user? If yes, then rights are being ignored! – Jaroslav Kucera Oct 21 '17 at 6:50
  • I am not elevated to root. – ScottF Oct 21 '17 at 7:13
  • @JaroslavKucera If they own the folder then they shouldn't need root, and they'd get some error, which they presumably report here. – Sparhawk Oct 21 '17 at 8:05
  • Notice that Linux has directories, not folders. – Basile Starynkevitch Oct 21 '17 at 9:24
4

Note

This post was made before OP gave the additional info that he's using a windows filesystem (NTFS) on a linux machine. I was under the impression he's using a native linux filesystem.


You need to set the read, write and executable flag for the owner, and the read, executable flag for the group for mydirectory. The executable flag is needed to enter the folder. Without it you get a "permission denied" when trying to cd myfolder as a user belonging to the group or other.

chmod 755 myfolder is giving access for the group and others, or chmod 750 myfolder just giving access for the group and lock others out.

Set the ownership to root and the group to users:

sudo chown root:users myfolder

Now, only root can create new files in myfolder ie. sudo touch mytest the new file gets the ownership root and the group root.

To force new files getting the group users, you need to set the SGID bit to myfolder.

this can be done in two ways, which results are equal

sudo chmod +s myfolder (adding the sgid bit) or sudo chmod 2755 myfolder (same + user, group, others)

doing a ls -l should show something like this:

drwsr-sr-x myfolder # last x optional depending on your others setting

if you now sudo touch mytest2 in myfolder, mytest2 belongs to root, and the group users with the permission 644

Existing Files in myfolder would be treated like this:

cd myfolder
sudo chown root:users *
sudo chmod 644 *

1 = execute
2 = write
4 = read

read + write = 4 + 2 = 6

P.S.: You can replace root with any user, users with any group


Update as requested by @Rastapopoulos a further explaination

Let's assume myfolder belongs to tom

When doing a chmod -R 444 myfolder/ you set the folder for user (tom), group, others to read only and all files within it, too So no nobody would be able to enter the folder, even tom (except root) because it's lacking the executable flag.

When doing a chmod 644 myfolder tom still can't enter the folder. The correct way would be to set the read, write, executable flag for tom, and the read executable flag for the group/others.

(executable flag = 1)

ie. chmod 755 myfolder (only setting permission for myfolder, not files)

To change only the permission for files in myfolder but not the permission for myfolder you'd do a:

chmod 444 myfolder/* 

But you might probably still want to edit/write your files as owner/tom so you'd rather do a

chmod 644 myfolder/* (or 640)
  • Thanks for the instructive answer. Could you by any chance explain what was the problem in OP's command? – Rastapopoulos Oct 21 '17 at 9:38
  • ...added an update to the end of my post. – Michael D. Oct 21 '17 at 9:58
  • Thanks! Still strange that he had write access even after doing chmod -R 444 myfolder/ though, no? – Rastapopoulos Oct 21 '17 at 10:04
  • root can do everything :) – Michael D. Oct 21 '17 at 10:09
  • Yes, I think that must be the issue too, but OP said that he's not elevated to root, so I was wondering whether there might have been another possibility. Thanks! :) – Rastapopoulos Oct 21 '17 at 10:11
1

The /etc/fstab entry in your update is rather important in this problem:

UUID=6F7C5E910607D747 /media/storage1 ntfs-3g uid=1000,gid=1000,umask=0022,auto,rw 0 0

This means it's a NTFS filesystem, and the uid, gid and umask options will essentially hard-code all the Linux-visible permissions on that disk, independently of the real NTFS ACLs. Essentially, these mount options will give one user total access to that filesystem and all of its files. The normal commands cannot change the permissions assigned by mount options.

With a bit of one-time work, you could switch to using the real NTFS file and directory permissions instead.

First, find the device name corresponding to that UUID:

sudo blkid | grep 6F7C5E910607D747 | cut -d : -f 1

Then unmount that filesystem, and run ntfsusermap /dev/<device w/the NTFS filesystem you unmounted>. It will list some files on that filesystem and ask you to identify the user or group that would best correspond to the Windows user/group that owns the file. Once enough users/groups have been identified, the command will produce a UserMapping file in the current directory. (Example run: http://jp-andre.pagesperso-orange.fr/ntfsusermap.html )

Now mount the NTFS filesystem again, make a directory named exactly like /media/storage1/.NTFS-3G and place the UserMapping file in that directory. Unmount the NTFS filesystem again, and remove the uid, gid and umask options.

Mount the NTFS filesystem for the third time, and now the file permissions will reflect the real NTFS ACLs. You can now modify the file and directory permissions using the usual Linux commands, and those changes will also be effective when you're using that filesystem with Windows too.

0

You can use the chattr +i <file> command to make the file immutable. I haven't tested this, but I'm pretty sure it will work when the underlying filesystem is ntfs.

You would then have to execute chattr -i <file> to remove the immutable flag.

Update: As pointed out in the comments,this only works on ext* file systems.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.