# Why are files in a smbfs mounted share created with executable bit set?

I mounted a samba share using the smbmount command:

$sudo smbmount \\\\foo\\bar /mnt/bar -o user=tom  When I create new files, they get created with the executable bit set for owner, group and world. For e.g. $ touch hello.txt
\$ ls -la hello.txt
-rwxr-xr-x 1 root root 0 Dec  2 12:28 hello.txt


The same file when created on a NFS mounted share sets up correct permissions without any executable bit set.

Why is this happening? How can it be fixed?

NFS was invented in the Unix world and so understands traditional Unix permissions out of the box. (The ACL of modern unix systems are another matter, but recent implementations of NFS should cope with them.)

Samba was invented in the IBM/Microsoft PC world, to exchange files with systems that had no permissions beyond read-only/read-write. It is now native to Windows. By default, Samba does not transmit Unix permissions. Depending on the configuration, either all files are marked executable (which is annoying) or all files (except directories) are marked non-executable (which is annoying).

There are various extensions to the Samba/CIFS protocol that make it more suited for Unix use. Try enabling Unix extensions in the server configuration:

[global]
unix extensions = yes

• Unfortunately in my company intranet, I don't have access to configure the server. Perhaps, it would be best to mount just using NFS on a Linux client. The bigger problem is on a Windows client, where configuring NFS is a pain in the neck. – vivekian2 Dec 3 '13 at 3:18
• @vivekian2 Indeed, if you have the choice, I definitely recommend using NFS on a Linux client and SMB on a Windows client. – Gilles 'SO- stop being evil' Dec 3 '13 at 10:04

This sounds like your issue, titled: Copied files gain execute bit on Samba/CIFS.

excerpt

After copying a file with rw-r----- on a CIFS-mounted volume, the copy gets rwxr-----. So it's gaining the execute bit:

Further down the page, setting map archive = no in /etc/samba/smb.conf:

excerpt

  [Global]
<snip>
map archive = no
<snip>

• This certainly solves the problem of files saved from Windows gaining the execute flag. Thanks! Another mad default, has anyone used archive flags in the past 2 decades? :) – Rennex Feb 15 '17 at 18:40

You might try: mount -t cifs

Google "mount cifs" for usage, it's not hard to understand, but you'll want to set options using the -o flag:

User and group are id's, as in numeric not the text alias. These options will ensure that you have r/w access, permissions are controlled by the mount no the server, and specifically file_mask=0664 will ensure that your files are not executable. On top of this you'll be able to work with your samba shares as local directories.

• In recent version of samba one may have to use file_mode=0644,dir_mode=0755 – Jokester Dec 6 '17 at 2:14
• WARNING: CIFS mount option 'dmask' is deprecated. Use 'dir_mode' instead. WARNING: CIFS mount option 'fmask' is deprecated. Use 'file_mode' instead. – Hubbitus Jul 12 '19 at 12:53

You can find out why this is happening from the following explanation on the Samba web site under the File Permissions and Attributes on MS-DOS and Unix section:

https://www.samba.org/samba/docs/using_samba/ch08.html

It has to do with mapping the System, Hidden and Archive bits for an MS-DOS filesystem.

An MS-DOS filesystem doesn't make use of executable bits so the three executable bits on the Unix filesystem are reused to represent the System, Hidden and Archive bits for the MS-DOS filesystem.

So when you view the file permissions using ls -l in Unix, you're viewing the file permissions suitable for MS-DOS (or Windows) keeping in mind that the three executable bits in Unix represent the System, Hidden and Archive bits for MS-DOS.

In smb.conf, however, you can turn this mapping off for a share with:

map archive = no
map system = no
map hidden = no


and force the mode on creation of files with:

force create mode = 0660

• It turned out to be so simple... Thank you for explanations! – anton_rh May 31 '18 at 13:18

I use a QNAP TS439 - and had this issue with files being executable.

Although I had to use the following in my /etc/fstab file

//192.168.0.1/audio /media/audio cifs credentials=/home/cheese/.smbcredentials,uid=1000,file_mode=0664,iocharset=utf8  0  0