I have an Arch linux machine that uses the following fstab entry to mount a share:
//192.168.3.1/Documents /mnt/ cifs credentials=/home/tal/.smbcredentials,rw,x-systemd.automount,iocharset=utf8,file_mode=0600,dir_mode=0700,uid=tal 0 0
The server that is sharing the folder is a Windows server, and the partition the shared folder is on is NTFS.
Using the above fstab entry, the share mounts at boot just fine. As expected, all files at /mnt/
appear to be owned by 'tal' and have the permissions 0600. Newly created files under /mnt are also owned by tal (whether they are created by root or tal), and have the 0600 permissions, as expected.
The problem is that if I have a file under /mnt:
-rw------- tal root 1000 test.txt
and I run this on it:
sed -i -e '1,2d' test.txt
to delete the first 2 lines, the 2 lines are deleted, but the file's permissions change to:
-r-------- tal root 1000 test.txt
Why is sed changing the file permissions? Looking at the inode of test.txt, I can tell that sed's -i
option recreates the file with the new content rather than modifying the file, but that shouldn't really matter - all newly created files under /mnt
should get the 0600 permissions.
As a test, I modified the same file with vim and checked the inodes too. Vim also recreates the file in place rather than modifying it, but when vim does it, the permissions remain as 0600.
nounix
flag?umask
?vim
is probably "smart" enough to replicate the perms of the original file.sed
doesn't, with perms on created files being set automatically by the user'sumask
. BTW, see themount.cifs
man page -file_mode
anddir_mode
only apply if the server does not support the CIFS Unix Extensions. Note also that permissions can be set in the share defintion on the server.