I have a FreeNAS server on a network with OSX and Windows clients. When the OSX clients interact with SMB/CIFS shares on the server, they are causing permission problems for all other clients.

Update: I can no longer verify any answers because we abandoned the project, but feel free to post any help for future visitors.

The details of this behavior seem to also be dependent on the version of OSX the client is running. For this question, let's assume a client running 10.8.2.

When I mount the CIFS share on an OSX client and create a new directory on it, the directory will be created with drwxr-x-rx permissions. This is undesirable because it will not allow anyone but me to write to the directory. There are other users in my group which should have write permissions as well. This behavior happens even though the following settings are present in smb.conf on the server:

create mask= 0666
directory mask= 0777
force directory mode= 0775
force create mode= 0660

I was under the impression that these settings should make sure that directories are at least created with rwxrwxr-x permissions. But, I guess, that doesn't stop the client from changing the permissions after creating the directory.

When I create a folder on the same share from a Windows client, the new folder will have the desired access permissions (rwxrwxrwx), so I'm currently assuming that the problem lies with the OSX client.

I guess this wouldn't be such an issue if you could easily change the permissions of the directories you've created, but you can't. When opening the directory info in Finder, I get the old "You have custom access" notice with no ability to make any changes.

enter image description here

I'm assuming that this is caused because we're using Windows ACLs on the share, but that's just a wild guess.

Changing the write permissions for the group through the terminal works fine, but this is unpractical for the deployment and unreasonable to expect from anyone to do.

This is the complete smb.conf:

    encrypt passwords = yes
    dns proxy = no
    strict locking = no
    read raw = yes
    write raw = yes
    oplocks = yes
    max xmit = 65535
    deadtime = 15
    display charset = LOCALE
    max log size = 10
    syslog only = yes
    syslog = 1
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    smb passwd file = /var/etc/private/smbpasswd
    private dir = /var/etc/private
    getwd cache = yes
    guest account = nobody
    map to guest = Bad Password
    obey pam restrictions = Yes
    # NOTE: read smb.conf.
    directory name cache size = 0
    max protocol = SMB2
    netbios name = freenas
    workgroup = COMPANY
    server string = FreeNAS Server
    store dos attributes = yes
    hostname lookups = yes
    security = user
    passdb backend = ldapsam:ldap://ldap.company.local
    ldap admin dn = cn=admin,dc=company,dc=local
    ldap suffix = dc=company,dc=local
    ldap user suffix = ou=Users
    ldap group suffix = ou=Groups
    ldap machine suffix = ou=Computers
    ldap ssl = off
    ldap replication sleep = 1000
    ldap passwd sync = yes
    #ldap debug level = 1
    #ldap debug threshold = 1
    ldapsam:trusted = yes
    idmap uid = 10000-39999
    idmap gid = 10000-39999
    create mask = 0666
    directory mask = 0777
    client ntlmv2 auth = yes
    dos charset = CP437
    unix charset = UTF-8
    log level = 1

    path = /mnt/zfs0
    printable = no
    veto files = /.snap/.windows/.zfs/
    writeable = yes
    browseable = yes
    inherit owner = no
    inherit permissions = no
    vfs objects =  zfsacl
    guest ok = no
    inherit acls = Yes
    map archive = No
    map readonly = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = yes
hide dot files
force directory mode = 0775
force create mode = 0660
  • 1
    The [share] section will take precedence over the [global] section when two options are the same Nov 14, 2013 at 17:19
  • Can you post the entire smb.conf file? Nov 15, 2013 at 0:23
  • @CanadianLuke: Done Nov 15, 2013 at 10:54
  • Do you have full SSH access to your FreeNAS? Can you set folder permissions on the terminal? Nov 15, 2013 at 16:35
  • @CanadianLuke: Yes, I have SSH access to the server and setting permissions through the terminal is no problem at all. Nov 15, 2013 at 17:16

5 Answers 5


To prevent OS X clients of changing permissions, you need to add

unix extensions = no

to the [Global] section of your smb.conf

And/or add something like

force security mode = 0660
force directory security mode = 02770

to your share definitions to preserve group-write rights.

  • The only one working solution I was able to find. Thanks!
    – Antonio
    Oct 16, 2014 at 19:43
  • This Solution worked for me too, windows users/group permissions where being created correctly, but when a mac user would create a directory it would not comply to the user share definitions set even though they where forced. Thanks! Mar 15, 2016 at 19:21

Change your share definitions to contain just the following:

path = /path/to/folder
browseable = yes
writeable = yes
inherit permissions = yes

Now, change the permissions on the folders directly:

# chown user:group -R /path/to/folder
# chmod 2770 -R /path/to/folder (or 2775 for public read only)

The CHMOD command above will have "special" permissions applied, which allow folders dropped in the folder to take on the parent's permissions automatically. For this to take affect:

/etc/init.d/samba reload

The reload switch does not restart samba (kicking off current users), but reloads the configuration file.

As well, documented on the FreeNAS Wiki:

If permissions work for Windows users but not for OS X users, try disabling Unix Extensions and restarting the CIFS service.


if you are creating those folders inside the Terminal.app maybe setting the system wide umask to 002 (777 - umask = mask for executables and folders 666 - umask = mask for files) instead of 022 is a possibility


I have tried all the hints here, and nothing worked, so I did the brute force approach, and it works like a charm. Not very pretty, but it does the job.

crontab -e

and then add a line

*/2 * * * * chmod -R 770 /home/samba/work

I had no luck with the setting unix extensions = no – probably because I am using the VFS module vfs_fruit for enhanced interoparability with macOS clients.

If you are using vfs_fruit, the following setting does the trick:

fruit:nfs_aces = no

This will prevent macOS clients from writing their own ACLs and messing with the UNIX permissions.

This are the relevant parts of the [global] section of my smb.conf:

fruit:metadata = stream
fruit:model = MacSamba
fruit:posix_rename = yes
fruit:veto_appledouble = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
fruit:time machine = yes
fruit:nfs_aces = no
inherit permissions = yes
inherit acls = yes
acl group control = yes
vfs objects = catia fruit streams_xattr

Please note, that unix extensions is set to yes per default.

In the share, directories have drwxrwsr-x (i.e. SETGID bit set) permissions and belong to a common group of the users, that should have access. Additionally, directories have a default:group::rwx ACL (set with setfacl -m default:group::rwx $dirname).

  • 1
    Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Apr 19 at 10:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.