By default in macOS, you will see that each folder you create on a FC client will result with permissions in correlation with the umask 022 when you create a directory [777 – 22 = 755].
[Creating folder on the A-Class with Squash All]:
hostName:currentPath user$ mkdir Test_Folder
hostName:currentPath user$ ls -la | grep Test_Folder
drwxr-xr-x 2 user staff 4096 Apr 28 17:02 Test_Folder In the first column, you will see the file permissions. A “d” in front denotes that the name on that line is a directory (folder) and a dash (-) in front denotes that it’s a file. There are 9 other characters after that. Break up those 9 characters into 3 groups, and you'll get the permissions for each user group (user, group, and world).
A “r” denotes read permissions, a “w” denotes write permissions, and a “x” denotes execute permissions. If there is a dash where a character should be, then that denotes that a particular file permission doesn’t exist.
Let’s take this for example:
1. Created a folder on the A-Class = Test_Folder and re-shared the folder via SMB (NASGW)
- Permissions from FC Directory Creation
drwxr-xr-x 2 user staff 4096 Apr 28 17:02 Test_Folder
2. Since the NASGW doesn’t support extendedACLs, the NASGW can only inherit and respect POSIX Permissions. When you execute permissions via Folder Share on the NASGW, it’s parsing and writing the allowed users to access the SMB share via the smb.conf file stored on the NASGW. These permissions in the smb.conf only grant access to the SMB share(s). Once you have established a connection to the SMB share, there is no permission or ACL that defines the LDAP user you used to authenticate; hence, establishes its permissions rights with the World user group permissions [R/W] to allow the user to read and write data. This only applies to folders and files that were created by squash all SAN client.
Therefore, when you create a folder on the SAN via FC, it's automatically going to write folders/files with the umask that the machine is configured with.
Example - Creating two folders:
- Creating a folder via a SAN client with default umask 022.
- Creating a folder via a NAS (SMB) client with directory and file mask dictated by Samba.
Key
- FC = FC_DIR via SAN client.
- SMB = SMB_DIR via NAS (SMB) client.
drwxr-xr-x 2 user 1000 4096 Apr 28 18:36 FC_DIR
drwxrwxrwx 2 2002 3000 4096 Apr 28 18:35 SMB_DIR
If you notice that when the folder was created on the SAN Volume with a SAN client, it gave the folder drwxr-xr-x meaning that when the SMB user wants to write to that folder, they will not be able to since the POSIX UID/GID are completely different and the NAS (SMB) user will rely on the the R/W properties of the World user group. If you notice, that only the character x for the World user group is enabled for the FC_DIR directory.
When the folder is created on the SMB share, it created the folder [SMB_DIR] with drwxrwxrwx allowing everyone to R/W when they access the SAN volume via FC. The NASGW is designed to always write folder and files to the FS with 777 permissions. Keep in mind that the NASGW is also a FC Linux client.
What’s the solution?
- Changing the umask of the OS X FC clients with 000 umask
- Apple published a well written document that should illustrate on how to change this with each specific macOS build.
- https://support.apple.com/en-us/HT201684
- https://en.wikipedia.org/wiki/Umask
Umask setting for OS X Yosemite (10.10.X) and above
In OS X Yosemite 10.10.3 and later, open a termial and run this command:
sudo launchctl config user umask 000 You will have to reboot for the change to take effect.
For earlier OS X versions, see the apple support forum at https://support.apple.com/en-us/HT201684
There are several customers that have found this as a feasible workaround. Once you change the umask on the macOS client, you will be able to R/W simultaneously across SMB and FC.
Promise Technology Technical Support >
