I've tried all kinds of Google searches, but I can't find a straight answer to my question.

Do Unix concepts like owner, group, permissions bits, etc., work with SMB?

My first thought is that SMB is probably designed to work with the Windows model of security (i.e., ACLs), so it probably doesn't understand Unix security concepts. But then again, maybe somebody has extended the protocol to add support for that?

Basically, I have Samba running on one Linux box, and I can mount the file share on another Linux box, but I can't do anything permissions-related. Running chown or chgrp on the client returns success, but the actual permissions reported haven't changed. Similarly, chmod is doing something strange. Even if I do chmod 000 the file is still world-readable and world-executable. In fact, it appears to be impossible to turn off execute permission at all.

Is this because I configured something wrong, or is it just that SMB does not support Unix file permissions?

  • 2
    How does the smb.conf looks like, or the part of the share?
    – Z0OM
    Commented Jul 24, 2023 at 17:03

3 Answers 3


If you create your samba share you can set the following options for the share in your smb.conf on the server, but sometimes you can't get samba to set proper permissions on created directories if you don't use the right ones(this is only an example of what you can set, but you can't set them all together, and don't use the example settings):

path                    = /usr/share/anonymous
valid users             = anonymous
hosts allow             =
writeable               = yes
guest ok                = no
public                  = no
browsable               = no
printable               = no
usershare allow guests  = no
usershare owner only    = no
usershare max shares    = 0
read only               = no
create mask             = 0644
directory mask          = 0644
valid users             = %S
create mask             = 664
force create mode       = 664
security mask           = 664
force security mode     = 664
directory mask          = 2775
force directory mode    = 2775
directory security mask = 2775
force directory security mode = 2775

Check all the sources, which parameters you have to set and try them:


My first thought is that SMB is probably designed to work with the Windows model of security...

SMB = server message block. It is not SAMBA.


Server Message Block (SMB) is a communication protocol[1] originally developed in 1983 by Barry A. Feigenbaum at IBM[2] and intended to provide shared access to files and printers across nodes on a network of systems running IBM's OS/2. It also provides an authenticated inter-process communication (IPC) mechanism. In 1987, Microsoft and 3Com implemented SMB in LAN Manager for OS/2, at which time SMB used the NetBIOS service atop the NetBIOS Frames protocol as its underlying transport. Later, Microsoft implemented SMB in Windows NT 3.1 and has been updating it ever since, adapting it to work with newer underlying transports.

So SMB was not designed work with a [Microsoft] Windows model of security; Server Message Block came long before Windows 3.1 in 1992, and windows95 in... 1995. It is a protocol that everyone began to use including Microsoft, and has been updated to SMB 2.0 and 3.0. Like everything back in the early days of computing, security concepts were largely non existent; to say Windows model of security is grossly ambiguous or non-specific.

Basically, I have Samba running on one Linux box, and I can mount the file share on another Linux box...

SAMBA is a linux software suite that provides interoperability to Microsoft Windows systems providing file & print services and to seamlessly integrate linux servers into Active Directory environments. Can you export a file share using SAMBA using SMB (or obsolete CIFS?) and have another linux server mount it, sure. But I would not do that, based on the simple definition and purpose what SAMBA is supposed to do. Between linux and linux my recommendation would be using NFS vers=4.2. If you want to specifically use SAMBA making use of SMB3.0 then I would scour the samba.org website for all the configuration options in /etc/samba/smb.conf to properly export and mount such a share to that linux applies its file system stuff (permissions, etc.) which today would/should be over the SMB3.0 protocol.

it appears to be impossible to turn off execute permission at all.

this makes me think of using an NTFS file system in linux... https://unix.stackexchange.com/questions/604674/chmod-is-not-working-on-ntfs-3g-partition#:~:text=For%20either%20chmod%20or%20chown,commands%20can%27t%20possibly%20work.&text=This%20will%20mount%20with%20specified,755%20and%20files%20mode%20644%20.

if you are using ntfs-3g in linux to mount an NTFS file system, instead of a linux supported file system such as XFS or EXT3/4, then you will always see execute permissions on everything, unless you explicitly mount it to not be so.

Do Linux file security settings work on SMB?

I was say yes, but from what you've described you have left out a lot of important context - Linux version being used, SAMBA version being used, your smb.conf and the SMB protocol actually in effect, so I would guess that you have something misconfigured... you mentioned maybe somebody has extended the protocol to add support for that ... that answer would be in how SMB has been updated to it's latest version being 3.0. I have zero problem using linux samba export via 3.0 and a microsoft win10 accessing it, with samba security=user and passdb backend = tdbsam.


SMB (Server Message Block), also known as CIFS (Common Internet File System), is a network file-sharing protocol primarily used by Windows systems. it does not directly support Unix-style permissions (owner, group, permissions bits) as found in Unix-like systems (Linux, macOS, etc.).

When you mount an SMB/CIFS share from a Samba server on a Linux client, the client tries to map the SMB permissions to Unix-style permissions to provide some compatibility and consistency. This is usually done using the **cifs VFS** module, which allows you to mount CIFS shares in a way that they appear as part of the local file system hierarchy.

However, there are some limitations when it comes to mapping SMB permissions to Unix-style permissions. The behavior you described, such as the inability to change permissions using chmod or chown and strange behavior with execute permissions, can be due to the way SMB permissions are mapped to Unix-style permissions.

Here are a few points to consider:

  1. User Mapping: Ensure that you have proper user mapping configured between the Linux client and the Samba server. If the mapping is not correct, the client may not have the necessary permissions to modify files on the share.

  2. ACLs (Access Control Lists): SMB/CIFS supports Access Control Lists (ACLs) that provide more granular control over file permissions compared to traditional Unix-style permissions. If the share has ACLs set, they might take precedence over the Unix-style permissions.

  3. CIFS Unix Extensions: Samba provides a parameter called cifs Unix extensions, which can be enabled or disabled in the Samba server configuration. When enabled, the client can have more Unix-like behavior with permissions. Make sure this option is enabled in your Samba server configuration.

  4. Mount Options: When mounting the SMB share on the client, you can specify mount options to control the way permissions are handled. For example, you can use the uid, gid, file_mode, and dir_mode options to set default ownership and permissions for files and directories on the mounted share.

It's worth noting that while SMB/CIFS does not natively support Unix-style permissions, Samba tries to provide some compatibility and mapping to make it easier to work with Unix-like clients. However, due to the inherent differences between the permission systems, there may be some limitations and inconsistencies.

If you require full Unix-style permissions and features on a Linux client, you might consider using NFS (Network File System), which is specifically designed for Unix-like systems and provides native Unix-style permissions and ownership management.

  • 3
    given it is 2023, you might want to edit your reference to CIFS; I would not say SMB == CIFS anymore, nor just refer to SMB as SMB; SMB2 (and SMB3) protocols are vast improvements to the original Server Message Block and that distinction should be recognized, as well as CIFS is a dialect of SMB and CIFS is now obsolete.
    – ron
    Commented Jul 24, 2023 at 17:51

You must log in to answer this question.

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