Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

Methods For Fine-Tuning Samba Permissions

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,487
Thanks
1,513
#1
Caveat: This is a work-in-progress
Correctly setting permissions on any server requires care and planning. In the case of Samba servers this becomes even more important for the server administrator because he or she has to understand the differences between Windows and Unix permissions models (Windows ACLs vs ZFS ACLs vs Unix mode bits, Windows SIDs vs Unix UID/GID, etc), as well as Samba's methods to implement the Windows permissions model on Unix servers. To this end, Samba offers several points of control for permissions. While this is extremely useful for experienced admins (and is necessitated by the sheer variety of devices and operating systems supported by the Samba project), the flexibility of samba permissions often trips up new users. This how-to will cover the basic points of control for Samba (CIFS) permissions and give an example of a fairly simple working Samba configuration on a FreeNAS server.

Access Control Methods for FreeNAS Samba Servers
Access control for SMB shares on a Windows server are determined through two sets of permissions: NTFS Access Control Lists (ACLs) and share permissions (which are primarily used for access control on Windows filesystems that do not support ACLs). In contrast with this, there are four primary access control facilities for Samba on FreeNAS: dataset user and group permissions in the FreeNAS webgui, Access Control Lists (ACLs), Samba share definitions, and share permissions.

Dataset User and Group Permissions
Dataset user and group permissions are controlled through the FreeNAS webgui by expanding "Storage" in the left pane of the webgui, clicking on the "View Volumes" button, selecting the dataset corresponding to your samba share in the right panel, then clicking on the "Change Permissions" icon in the lower-left side of the aforementioned panel. Permissions type should be set to "Windows" regardless of client type. By default "full control" of your samba share is granted to the owner(user) and owner(group), and "read-only" access to all other authenticated users. Additional fine-tuning should be managed through modifying filesystem ACLs. This procedure is more fully explained in the freenas handbook at the following site: http://doc.freenas.org/11/storage.html#change-permissions

Access Control Lists (ACLS)
An access control list (ACL) is a data structure containing permissions attached to a file or folder. An ACL contains zero or more Access Control Entries (ACEs) which specify which users or groups are allowed or denied access to the file or folder. ZFS (the filesystem used by FreeNAS) provides a pure ACL model, where all files have an ACL. There are two types of Access Control Lists (ACLs) - trivial and non-trivial. Trivial (default) ACLs only represent the traditional UNIX owner/group/other entries. These are initially configured via webgui as described above in "Dataset User and Group Permissions". Non-Trivial ACLs contain Explicit Access Control Entries (ACEs), which cannot be expressed through traditional Unix mode bits. Typically, permissions on a FreeNAS Samba server in a multi-user environment are managed through creating and maintaining explicit ACEs. ACLs under ZFS are broadly compatible with the NTFS ACLs used by Windows Servers, which allows FreeNAS samba servers to be an almost drop-in replacement for a Windows file server.

Modifying Access Control Lists (ACLS)
Windows File Explorer is by far the simplest and best tool to manage ACLS on a FreeNAS server. To use fine-tune permissions using File Explorer, navigate to \\IP-address or \\hostname, right-click on your share, click on "properties", then click on the "security tab". The various permissions options are documented on various microsoft websites such as: http://windows.microsoft.com/en-us/windows/what-are-permissions#1TC=windows-7 and https://msdn.microsoft.com/en-us/library/bb727008.aspx.

There are two methods to modify ACLs from the FreeNAS command line: smbcacls and setfacl. smbcacls is a part of samba, and at present lacks the ability the recursively set permissions through a file tree. If you don't have a windows PC available to configure permissions when setting up your samba shares, you can use smbcacls to add the required access control entries prior to copying data.
Example usage of setfacl:
setfacl -m g:"DOMAIN\domain admins":full_set:fd:allow,g:"DOMAIN\domain users":modify_set:fd:allow,owner@:modify_set:fd:allow,group@:modify_set:fd:allow,everyone@::fd:allow /mnt/dozer/SHARE

Once permissions have been fine-tuned at the root of a share through setfacl, the permissions can be recursively applied by running the following command locally:
winacl -a clone -rv -p /mnt/dozer/SHARE

Example usage of smbcacls:
smbcacls //<IP-address>/<share name> / -U <user name> --add ACL:<user>:type:flags/permissions
smbcacls //192.168.24.42/TestShare / -U root --add ACL:TestUser:ALLOWED/3/FULL

The above command will add an ACE for the user "TestUser", grant full control to the existing folder and enable inheritance so that all newly created files / folders under TestShare will also allow TestUser full control. Valid values for "permissions" include "READ", "CHANGE", "FULL". The smbcacls utility is more fully documented in its manpage here: https://www.samba.org/samba/docs/man/manpages/smbcacls.1.html


Behavior Differences between NTFS ACLs and ZFS ACLs and Some Caveats

ZFS ACLs and NTFS ACLs are largely identical, but there are some minor differences:
  • There is no strict equivalent of Special ACEs in a windows environment and so Samba has to translate these into something that windows understands. This behavior is controlled by the share configuration parameter "nfs4:mode = special | simple", which in FreeNAS 11.2 and earlier defaults to "nfs4:mode = special". In 11.3 and later, this parameter defaults to "simple". In the case of "simple", owner@ and group@ are mapped to CREATOR-OWNER and CREATOR-GROUP respectively and windows behavior for these well-known-SIDs is reproduced.
  • Windows documentation suggests that if some but not all requested access bits have been allowed, then DENY aces will still apply even if they only deny bits among those already allowed. This has the somewhat bizarre result that an ACL can allow certain permissions individually but deny them in combination. The NFSv4 ACL algorithm doesn't have this property.
  • The Windows UI places restrictions on the order of ACLs. Hence, it is best to let Samba handle generating the ACLs (either through Windows Explorer or smbcacls). This issue is can be worked around in the ixnas module starting in FreeNAS 11.3 by setting the share-level auxiliary parameter "ixnas:zfsacl_sortaces = true"
  • Windows allows to open a file without the read, write or execute permission. For example to read the permissions of a file. The practical result of this difference is that files and folders on the FreeNAS Samba server will be invisible to a user if he or she does not have at a minimum "Read attributes".
  • In FreeBSD presently "write data" (w) implies "delete" (D) and "delete child" (d). This issue is mitigated in the ixnas module starting in 11.3.
Samba Share Definition Access Controls
There are edge cases where a FreeNAS Samba administrator may need to use these parameters, but when in doubt, use ACLs to define permissions for samba shares. It is highly advisable to use the easiest to maintain and the least ambiguous method for controlling access, and it can be hard to predict how different access control methods will interact. However, in some situations it is distinctly desirable to force all file system operations as if a single user were doing so. The use of the force user and force group behavior will achieve this. In other situations it may be necessary to use a paranoia level of control to ensure that only particular authorized persons will be able to access a share or its contents. Here the use of the valid users or the invalid users parameter may be useful.
root@FOOTEST:/usr/ports/net/samba49 # ls -l /zroot/
total 27
drwxr-xr-x+ 3 root wheel 4 Jun 10 09:22 insens
drwxr-xr-x 71 root wheel 85 Jan 16 06:30 newports
drwxrwxr-x 7 root wheel 8 May 30 05:47 samba
drwx------+ 3 root wheel 3 Jan 15 12:47 test
drwxr-xr-x+ 6 root wheel 6 Feb 13 15:55 users
drwxr-x---+ 2 root wheel 11 Dec 27 10:15 zfsquota


Share Definition Auxiliary Parameters Affecting Permissions
Code:
force group:  Specifies a UNIX group name that will be assigned as the default primary group for all users connecting to this service.
force user:   Specifies a UNIX username that will be assigned as the default user for all users connecting to this service. This is useful for sharing files. Incorrect use can cause security problems.
read list:    List of users that are given read-only access to a service. Users in this list will not be given write access, no matter what the read-only option is set to.
valid users:  List of users that should be allowed to login to this service.
write list:   List of users that are given read-write access to a service.

A name starting with a '@' is interpreted as an NIS netgroup first (if your system supports NIS), and then as a UNIX group if the name was not found in the NIS netgroup database. A name starting with '+' is interpreted only by looking in the UNIX group database via the NSS getgrnam() interface. A name starting with '&' is interpreted only by looking in the NIS netgroup database (this requires NIS to be working on your system). The characters '+' and '&' may be used at the start of the name in either order so the value +&group means check the UNIX group database, followed by the NIS netgroup database, and the value &+group means check the NIS netgroup database, followed by the UNIX group database (the same as the '@' prefix).

Example: valid users = greg, @pcusers

Share Permissions
Permissions set on shared directories are called share permissions, and they determine who can use shared directories over the network, and in what manner. These are the only access control method available for shared directories on FAT volumes on Windows servers, and in the Windows world are generally recommended only for shares on filesystems that lack ACL support.
In Samba, Share Permissions are handled through the share_info.tdb file and function independently of file system permissions. The share-level permissions as defined here only represent the maximum level of access a user or group has in a share. These can provide a relatively simple and intuitive way to manage access control in situations where managing access control through NTFS / ZFS ACLs is impractical or undesirable. In the absence of specific restrictions, the default setting in Samba is to allow the global user Everyone - Full Control (full control, change and read).

Share Permissions can be modified locally on the FreeNAS server by using the command line utility sharesec, which is a part of the Samba Suite. An administrator will need to view the idmap entries on the local FreeNAS servers to determine the appropriate SID value for the user / group to which he or she wishes to grant access. A sample command to add full access for SID S-1-5-21-1866488690-1365729215-3963860297-17724 on the share "test" is as follows: sharesec test -a S-1-5-21-1866488690-1365729215-3963860297-17724:ALLOWED/0/FULL.

Share Permissions can also be managed through the Computer Management Console from a Windows client while authenticated with a user who has appropriate privileges.

The Share-level ACL can be viewed locally from the command line on a FreeNAS server by entering the command sharesec --view-all or sharesec <share_name> -v. For instance, if a FreeNAS server has the share test, the ACL on test can be viewed through the command sharesec test -v. Sample output from this command is as follows:
Code:
[root@rivendell] ~#sharesec test -v
REVISION:1
CONTROL:SR|DP
OWNER:
GROUP:
ACL:S-1-1-0:ALLOWED/0x0/FULL

In the case that share_info.tdb file an entry for a share, samba will fake-up a "FULL CONTROL" ACE for S-1-1-0 (everyone).

Glossary
Access Control List (ACL)

An access control list (ACL) is a data structure containing permissions attached to a file or folder. An ACL contains zero or more Access Control Entries (ACEs) which specify which users or groups are allowed or denied access to the file or folder. The access control list for a file or folder can be viewed through the command line utility getfacl and set through the command line utility setfacl. There are multiple models of ACLs. Examples include NTFS, NFSv4, and POSIX-draft. ZFS on FreeNAS uses the NFSv4 model.

Access Control Entry (ACE)
An access control entry (ACE) is an element in an access control list. Each ACE contains the following components in the following order: Access Control Entry Type (ACE Tag and Qualifier), Access Permissions, Inheritance-Flags, and ACE Type (Deny | Allow). Examples of Access Control Entries - group@:rwxpDdaARWcCo-:fd-----:allow and group:IT:rwxpDdaARWcCo-:fd-----:allow

Special Access Control Entry
Special Access Control Entry Types consist of: owner@, group@, and everyone@. owner@ specifies the access granted to the owner of the file or folder. group@ specifies the access granted to the owning group of the file or folder. everyone@ specifies the access granted to any user or group that does not match any other ACE in the access control list. If an ACL only contains owner@, group@, and everyone@ ACEs, then it is considered a Trivial ACL.

Explicit Access Control Entry
Explicit Access Control Entry Types are indicated by "user" or "group". user - specifies the access granted to an additional user of the file or folder. This entry must contain a valid username or UID. Example: user:Bob. group - specifies the access granted to an additional group of the object. The entry must contain a valid groupname or GID. Example: group:Domain Admins.
Code:
     everyone@:r-x---a-R-c--s:-------:allow
               ||||||||||||||:|||||||
  (r)read data +|||||||||||||:||||||+ (I)nherited
  (w)rite data -+||||||||||||:|||||+- (F)ailed access (audit)
root@FOOTEST:/usr/ports/net/samba49 # ls -l /zroot/
total 27
drwxr-xr-x+  3 root  wheel   4 Jun 10 09:22 insens
drwxr-xr-x  71 root  wheel  85 Jan 16 06:30 newports
drwxrwxr-x   7 root  wheel   8 May 30 05:47 samba
drwx------+  3 root  wheel   3 Jan 15 12:47 test
drwxr-xr-x+  6 root  wheel   6 Feb 13 15:55 users
drwxr-x---+  2 root  wheel  11 Dec 27 10:15 zfsquota

     e(x)ecute --+|||||||||||:||||+-- (S)uccess access (audit)
      a(p)pend ---+||||||||||:|||+--- (n)o propagate
      (d)elete ----+|||||||||:||+---- (i)nherit only
(D)elete child -----+||||||||:|+----- (d)irectory inherit
read (a)ttrib -------+|||||||:+------ (f)ile inherit
write (A)ttrib -------+||||||
  (R)ead xattr --------+|||||
(W)rite xattr ----------+||||
    read a(c)l ----------+|||
   write a(C)l -----------+||
change (o)wner ------------+|
          sync -------------+

Inheritance Flags
The purpose of using ACL inheritance is so that a newly created file or directory can inherit the ACLs they are intended to inherit, but without disregarding the existing permissions on the parent directory. By default, ACLs are not propagated.

Trivial ACL
An ACL is trivial if it can be fully expressed as a POSIX mode without losing information:

Code:
[root@rivendell] ~# getfacl /mnt/Tank/TestShare/
# file: /mnt/Tank/TestShare/
# owner: root
# group: wheel
     owner@:rwxp--aARWcCos:-------:allow
     group@:r-x---a-R-c--s:-------:allow
  everyone@:r-x---a-R-c--s:-------:allow


Non-Trivial ACL
An access control list containing one or more explicit Access Control Entries. Sample Non-Trivial ACL:
Code:
[root@rivendell] ~# getfacl /mnt/Tank/TestShare/
# file: /mnt/Tank/TestShare/
# owner: root
# group: wheel
     owner@:rwxpDdaARWcCos:fd-----:allow
     group@:rwxpDdaARWcCos:fd-----:allow
group:DOMAIN\Minions:r-x---a-R-c---:fd-----:allow
group:DOMAIN\Domain Admins:rwxpDdaARWcCos:fd-----:allow


Another example of a non-trivial ACL:
Code:
[root@rivendell] ~# getfacl /mnt/Tank/TestShare/
# file: /mnt/Tank/TestShare/
# owner: root
# group: wheel
     owner@:rwxpDdaARWcCos:fd-----:allow
     group@:rwxpDdaARWcCos:fd-----:allow
  everyone@:r-x---a-R-c---:fd-----:allow


FreeBSD will indicate whether an ACL is trivial by showing a + sign to the right of the POSIX mode in the output of ls -l.

Code:
root@FOOTEST:/usr/ports/net/samba49 # ls -l /zroot/
total 27
drwxr-xr-x+  3 root  wheel   4 Jun 10 09:22 insens
drwxr-xr-x  71 root  wheel  85 Jan 16 06:30 newports
drwxrwxr-x   7 root  wheel   8 May 30 05:47 samba
drwx------+  3 root  wheel   3 Jan 15 12:47 test
drwxr-xr-x+  6 root  wheel   6 Feb 13 15:55 users
drwxr-x---+  2 root  wheel  11 Dec 27 10:15 zfsquota


Security Identifier (SID)
In the Windows world, every user, user group, or other security principal has a unique identifier called its SID. SIDs will typically look like this: S-1-5-21-1004336348-1177238915-682003330-2132 following the form S-R-X-D0-D1-D2-D3-RID. The S indicates that the string is a SID. The R indicates the version of SID structure that is used in the SID. The X indicates the identifier authority value. The everyone group has an authority value of "1". Specific Windows users and groups will have an identifier value of 5 (NT Authority). D0 represents a subauthority value and when combined with D1-D3 represent a unique domain identifier. D1, D2, and D3 are three randomly generated 32-bit numbers. SIDs for accounts and groups in the Built-In domain have a domain identifier value of 32 (for example the Built-in Administrators group has a SID of S-1-5-32-544). The Relative identifier (RID) is a variable length number that is assigned to objects at creation and uniquely identifies particular accounts or groups relative to a domain. Windows ACLs use SIDs to uniquely identify users and their group memberships. Samba has the capability of mapping Windows SIDs to Unix UIDs / GIDs through various winbind idmap backends. Unix users and groups that do not have passdb entries in samba will have a SID pefix of S-1-22-1 for users and S-1-22-2 for groups.

Like Built-in accounts, "well-known SIDs" are also an exception to the "S-1-5-21-D1-D2-D3-RID" rule. For more information, consult Microsoft Windows documentation https://support.microsoft.com/en-us/kb/243330.

Resources
 
Last edited:

NetSoerfer

FreeNAS Aware
Joined
May 8, 2016
Messages
44
Thanks
13
#2
Great write-up, a real life-saver trying to setup and manage SMB shares for use by Windows clients and Unix servers.

So how would I best manage ACLs from a Windows machine, assuming I don't want the Windows user to be the owner of every single file? Set an explicit ACE everywhere for my Windows user?

Also, I'm running into issues when trying to access a share mounted on another Unix client: on the FreeNAS server, only the owner "UnixClientUserOnFreeNAS" has access to the shared directory, but the user on the Unix client "UnixClientUser" has another UID. I'm logged in to the FreeNAS server's samba, but since UnixClientUser doesn't have the same UID as UnixClientUserOnFreeNAS, the Unix client prevents access to the share. How do I fix this? Is there a better way than aligning UIDs/GIDs on both machines, or using root?

The link to the FreeNAS doc in Dataset User and Group Permissions is broken, it should be http://doc.freenas.org/9.10/storage.html#change-permissions or http://doc.freenas.org/11/storage.html#change-permissions instead of /freenas_storage.html.
 
Last edited:

vikozo6

FreeNAS Experienced
Joined
Oct 16, 2015
Messages
266
Thanks
2
#3
Hello
to manage share and user to you have a separate Server or do you manage all in FreeNas?
have a nice day
vinc
 

kdragon75

FreeNAS Expert
Joined
Aug 7, 2016
Messages
2,390
Thanks
555
#4
The practical result of this difference is that files and folders on the FreeNAS Samba server will be invisible to a user if he or she does not have at a minimum "Read attributes"
So in effect it behaves like the windows access based enumeration option?

ZFS (the filesystem used by FreeNAS) provides a pure ACL model, where all files have an ACL... Typically, permissions on a FreeNAS Samba server in a multi-user environment are managed through creating and maintaining explicit ACEs. ACLs under ZFS are broadly compatible with the NTFS ACLs used by Windows Servers, which allows FreeNAS samba servers to be an almost drop-in replacement for a Windows file server.
Does this mean that when setting permissions in Windows on a FreeNAS SAMBA share, we are setting the ZFS ACLs and as such, if we use sendzfs to migrate to a new server the ZFS ACLs will be moved over as well?
 

kdragon75

FreeNAS Expert
Joined
Aug 7, 2016
Messages
2,390
Thanks
555
#5
Hello
to manage share and user to you have a separate Server or do you manage all in FreeNas?
have a nice day
vinc
In FreeNAS you would set the least restrictive permissions required on the dataset, setup all of your users and groups and then use a windows PC (any PC not just a server) to manage the permissions. Just right click, select properties, security tab. As long as your connected to the share as a user set as the owner or owner group.

So, no you do not need a second server. Once setup you "manage" from your desktop.

I have not played with permissions much yet so my understanding may be off. Please correct me if I am wrong.
 
Joined
Dec 12, 2015
Messages
53
Thanks
1
#6
I am running 11.1-U6.3. I am trying to create either a specific samba share or a specific freenas account that will give the user access to only one specific directory. I created a user, gave that user a home directory, and even created a new samba share, but although that samba share does open to the correct directory, once logged in the user has access to everything. If they browse to the \\freenas suddenly all the other shares pop up and will grant them access to all data in the dataset.

I believe this could be accomplished by creating a new dataset for this particular user, but I don't want to do that. I also recognize that permissions would partially solve the problem, but I honestly don't want to mess with permissions on the entirety of the rest of my data just to restrict one user to a particular folder.

I realize that this is very likely user error on my part or a lack of education on what needs to be done. If anyone would be willing to walk me through it, I would appreciate it. Thank you!
 

Dave Genton

FreeNAS Experienced
Joined
Feb 27, 2014
Messages
133
Thanks
3
#7
Been looking into this as I keep booting 11-2U2.1 but finding I still cannot write to freenas and in many cases cannot even download, reboot back to 11-2U1 and it works fine. I don't have or use windows, I have macOS machines. I switched to SMB when Apple announced they are doing so so thinking the obvious, why should I need a windows machine to set ACL permissions ?? I want both windows and macOS to be able to access read/write in case folks come over using windows, but certainly don't use Windows as tools to build and wishing I stayed with AFS for 2 more years before making the switch, Time machine just now migrating and no reason for 10Gb with Samba everywhere.....performance if awful.
 

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,487
Thanks
1,513
#8
Been looking into this as I keep booting 11-2U2.1 but finding I still cannot write to freenas and in many cases cannot even download, reboot back to 11-2U1 and it works fine. I don't have or use windows, I have macOS machines. I switched to SMB when Apple announced they are doing so so thinking the obvious, why should I need a windows machine to set ACL permissions ?? I want both windows and macOS to be able to access read/write in case folks come over using windows, but certainly don't use Windows as tools to build and wishing I stayed with AFS for 2 more years before making the switch, Time machine just now migrating and no reason for 10Gb with Samba everywhere.....performance if awful.
Yesterday I merged in a commit to allow managing ACLs through the FreeNAS middleware. This is an important step towards having an ACL editor in the FreeNAS UI, and will make it so that a Windows computer won't be necessary. Regarding performance over SMB, internally I believe we've been able to saturate 10 gigabit on MacOS and TrueNAS, but we have really fast SLOG devices. Perhaps you can try adding the auxiliary parameter "strict sync = no" as an auxiliary parameter for your share.
 

Dave Genton

FreeNAS Experienced
Joined
Feb 27, 2014
Messages
133
Thanks
3
#9
Thanks, I do have sync writes disabled and use L2 cache SSD's etc however I don't host vm's over iSCSI any longer either... now its just media shares and backups via SMB but bigger boxes use 10Gb NIC's, its not awful with lots of tuneables but doesn't compare to multi-threaded AFP which can fill about any pipe you wanted to....SMB headaches last 2 years have just been difficult for mac users on freenas, ldap is impossible unless using AD and I succumb to that..But I tried all fixes for the 11-2U2.1 hot fix including ixnas vfs-object vs zfsacl, nothing I do allows read-write access to my smb shares over SMB from my Mac's....Oddly I can access a few shares, others I cannot, where each dataset/share it configured 100% EXACTLY the same, they just host differing data types, differing snapshot schedules etc.. but same user/group permissions on storage, same share configuration, all on same ZFS pool.. .only difference of course is the Homes which doesn't allow guest access or browsable on network...Tried for hours again last night, but rebooted back to 11-1U1 and Samba works fine...... Hope it gets fixed soon because I booted up a WIndows 10 VM last night and using explorer I cannot change any permission on any shares because it always says they have inheritable permissions no matter how far up or down I go in directory tree....not sure how I can use windows with root level permissions to set security permissions so SMB works properly to all my macOS devices. Windows shows everybody, user, and group but group is wrong.. macOS shows user read/write, everyone no access... always does, even on 11-1U1 and before, but always works for user or guest on shares guests are allowed...guess I been away from windows too long to properly set permissions using windows, unsure how to push that... I created a local login using same name as owner user account on freenas..but win10 always send domain/user or local_computer/user anyways depending on login used, which doesn't match freenas exactly.... hints ?
 

seanm

FreeNAS Experienced
Joined
Jun 11, 2018
Messages
279
Thanks
35
#11

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,487
Thanks
1,513
#12
@anodos also these 2 links no longer go to where they presumably once did:

http://doc.freenas.org/11/storage.html#change-permissions

http://windows.microsoft.com/en-us/windows/what-are-permissions#1TC=windows-7

This write-up is awesome, thanks for doing it! It really should be integrated into the User Guide IMHO, I don't see how anyone could setup non-toy SMB shares without (at least some of) this.
Thank you. I think I will probably rework this in 11.3 and get information formally in the user guide at that time. There are plans to have a GUI ACL editor in that release.
 
Joined
Dec 20, 2013
Messages
57
Thanks
8
#13
Thanks, I do have sync writes disabled and use L2 cache SSD's etc however I don't host vm's over iSCSI any longer either... now its just media shares and backups via SMB but bigger boxes use 10Gb NIC's, its not awful with lots of tuneables but doesn't compare to multi-threaded AFP which can fill about any pipe you wanted to....SMB headaches last 2 years have just been difficult for mac users on freenas, ldap is impossible unless using AD and I succumb to that..But I tried all fixes for the 11-2U2.1 hot fix including ixnas vfs-object vs zfsacl, nothing I do allows read-write access to my smb shares over SMB from my Mac's....Oddly I can access a few shares, others I cannot, where each dataset/share it configured 100% EXACTLY the same, they just host differing data types, differing snapshot schedules etc.. but same user/group permissions on storage, same share configuration, all on same ZFS pool.. .only difference of course is the Homes which doesn't allow guest access or browsable on network...Tried for hours again last night, but rebooted back to 11-1U1 and Samba works fine...... Hope it gets fixed soon because I booted up a WIndows 10 VM last night and using explorer I cannot change any permission on any shares because it always says they have inheritable permissions no matter how far up or down I go in directory tree....not sure how I can use windows with root level permissions to set security permissions so SMB works properly to all my macOS devices. Windows shows everybody, user, and group but group is wrong.. macOS shows user read/write, everyone no access... always does, even on 11-1U1 and before, but always works for user or guest on shares guests are allowed...guess I been away from windows too long to properly set permissions using windows, unsure how to push that... I created a local login using same name as owner user account on freenas..but win10 always send domain/user or local_computer/user anyways depending on login used, which doesn't match freenas exactly.... hints ?
@Dave Genton - did you figure out your issue? I am running macOS with SMB and now my FreeNAS is doing random reboots when I do a transfer. I replaced all the hardware, so now I know it has something to do with configuration. I'm so frustrated - I'm considering going over to AFP.
 

nojohnny101

FreeNAS Expert
Joined
Dec 3, 2015
Messages
1,452
Thanks
287
#14
@DCswitch I used to use SMB shares with MacOS but after upgrading to 11.2, the changed how samba permission work and you could no longer have "unsupported" share configurations (ie having SMB shares with UNIX permissions). I have since gone to NFS shares which are working fine but don't have the authentication I would like.

AFP is also depreciated so I'm not really sure what the "recommended" configuration is for MacOs users who want authenticated shares.
 
Joined
Dec 20, 2013
Messages
57
Thanks
8
#15
@DCswitch I used to use SMB shares with MacOS but after upgrading to 11.2, the changed how samba permission work and you could no longer have "unsupported" share configurations (ie having SMB shares with UNIX permissions). I have since gone to NFS shares which are working fine but don't have the authentication I would like.

AFP is also depreciated so I'm not really sure what the "recommended" configuration is for MacOs users who want authenticated shares.
@nojohnny101 I have no idea what's going on any more. SMB worked fine even with 11.2 and Mojave. I used it successfully for a very long time. Now- every time I do a large transfer- it either cuts out early or the FreeNAS does a random reboot. I hadn't changed anything, so what the heck is going on? I tested NFS a long time ago and found that transfers were much slower, but as much as it pains me- I slow transfer would be upgrade to what I'm going through now. And btw- I know this is software related. I changed out my FreeNAS motherboard, CPU, PSU, and even the LSI SAS SATA controller. I also tested the memory. Even with all that- I'm still going through these random reboots. I've been pulling my hair out now 3 weeks.
 

seanm

FreeNAS Experienced
Joined
Jun 11, 2018
Messages
279
Thanks
35
#16
If the FreeNAS is 'randomly' rebooting, then it's probably a kernel panic. Those can be logged, though I'm not sure the right way to do so with FreeNAS. You might start by going to System > Advanced and turning on 'enable debug kernel'.

PS: I'm also struggling with macOS + SMB permissions, though I'm not seeing any panics.
 
Joined
Dec 20, 2013
Messages
57
Thanks
8
#17
@seanm I think I'm done with 11.2. I never had these kind of issues with 11.1. It takes a lot of tweaking and even with that- it's still not stable.
 
Joined
Dec 20, 2013
Messages
57
Thanks
8
#18
Okay- I went back to version 11.1-U5 and right off the bat the install was better. I was seeing all sorts of weird errors here and there with 11.2. I saw no errors with 11.1-U5 other than the SMART service not working properly which is a known, fixable bug. That easy fix is to simply go to DISKS and remove SMART checking on your USB boot up thumb drive. I did that and rebooted and it was fixed. I reloaded all my settings from scratch and did a transfer from latest version of macOS Mojave 10.14.4 using SMB and it worked on the first shot. I haven't tested 11.1-U6 or U7, but they might be okay too. I haven't added any tunables yet- I'm going to add them one by one and test carefully. If anyone reading this is using SMB (even NFS) connecting to a macOS machine and running STABLE- please let me know what tunables/settings your're using. Also, please let me know if you're getting faster transfers with NFS or SMB.
 
Last edited:

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,487
Thanks
1,513
#19
@DCswitch I used to use SMB shares with MacOS but after upgrading to 11.2, the changed how samba permission work and you could no longer have "unsupported" share configurations (ie having SMB shares with UNIX permissions)..
There has been no change to how samba permissions work. The change in zfsacl that caused issues for some users has been reverted, and there is no intention of further modifying zfsacl in the future. Changes will be isolated to ixnas.
 

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,487
Thanks
1,513
#20
Okay- I went back to version 11.1-U5 and right off the bat the install was better. I was seeing all sorts of weird errors here and there with 11.2. I saw no errors with 11.1-U5 other than the SMART service not working properly which is a known, fixable bug. That easy fix is to simply go to DISKS and remove SMART checking on your USB boot up thumb drive. I did that and rebooted and it was fixed. I reloaded all my settings from scratch and did a transfer from latest version of macOS Mojave 10.14.4 using SMB and it worked on the first shot. I haven't tested 11.1-U6 or U7, but they might be okay too. I haven't added any tunables yet- I'm going to add them one by one and test carefully. If anyone reading this is using SMB (even NFS) connecting to a macOS machine and running STABLE- please let me know what tunables/settings your're using. Also, please let me know if you're getting faster transfers with NFS or SMB.
I use MacOS with the 11.2/11.3 daily. Currently on 10.14.4. Tomorrow I will do a large transfer on 11.2 and see if I can reproduce your problem. Some users have had issues caused by samba's new AIO settings in 4.9. We're tuning them in 11.2-U4 to make it more stable for home users (turning off AIO writes and tuning down AIO max threads).

Quick update: I could not reproduce the issue with reboots during file transfer from MacOS.
 
Last edited:
Top