I have an Arch linux machine that uses the following fstab entry to mount a share:

//        /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.

  • Is it perhaps related to this Configure CIFS mount point permissions - more specifically, to CIFS Unix extensions and the nounix flag? Commented Nov 21, 2015 at 23:06
  • 1
    what's your 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's umask. BTW, see the mount.cifs man page - file_mode and dir_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.
    – cas
    Commented Nov 22, 2015 at 0:05
  • Adding 'nounix' flag to fstab didn't help. I'm not sure, but I would guess that samba only supports unix permissions if the shared folder is on a unix-partition (ext2, ext3, ext4, etc). In my case, it's on an NTFS partition, which has no unix permissions for samba to disable, so it makes sense to me that nounix wouldn't be necessary. My umask is 0022, which should make new files 644, but it doesn't - new files get made with permissions set by file_mode in my case, which makes sense. The file_mode option I use definitely changes the apparent file permissions on the mounted share.
    – Tal
    Commented Nov 22, 2015 at 0:52

2 Answers 2


The man page for mount.cifs states the following:

The core CIFS protocol does not provide unix ownership information or mode
for files and directories. Because of this, files and directories will
generally appear to be owned by whatever values the uid= or gid= options are
set, and will have permissions set to the default file_mode and dir_mode for
the mount.  Attempting  to change these values via chmod/chown will return
success but have no effect.

In other words, sed is not changing the POSIX permissions, the CIFS file system simply does not understand them, so they are being ignored. Since your default file_mode is 0600, that's what all files will appear to have on this particular mount point.


Not sure it's related: I remember AD users have an option to specify "Main group" in user membership "if you have mac clients or posix apps"

  • Sorry for the noise. I understand and agree a down-vote is better than no-opinion. As this was my first post here at U&L.SE and I didn't see the green check I use to see at askubuntu, I thought this question didn't already get a good answer and I just wanted to give a possible track for anyone skilled enough with both Lunix & MS to dig further.
    – useful
    Commented Nov 8, 2017 at 16:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .