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?

5 Answers 5


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:

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, 2013 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. Dec 3, 2013 at 10:04

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


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:


  map archive = no

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:


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

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 (or file_mode=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.

  • That is not a solution. The files are still created executable on the server, but you see them as file_mode on the client, even if they really are executable on the server.
    – Adrian May
    Feb 24, 2023 at 12:19

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

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

You must log in to answer this question.

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