UNIX permission changes after copying to FreeNAS and back again via SMB

[seanm]

I create a file on my Mac with 'touch ~/Foo.txt', giving:

-rw-r--r-- 1 sean staff 0 8 Apr 14:29 Foo.txt

then I copy it to my FreeNAS (mounted with SMB) using 'cp -a' (or Finder) then back again:

-rwxrwxr-x 1 sean staff 0 8 Apr 14:29 Foo2.txt

Notice it went from 644 to 775. This does not occur if I do the same test with my macOS file server (it comes back with same permissions).

What's going on?

 

[anodos]

The ACL is inherited from the parent directory in the SMB share, which roughly translates into 775.

 

[seanm]

Thanks for your fast reply, but I'm not sure I grok it. Let me try posing a more exact question: what have I misconfigured here? What do I need to do to have lossless copies? Or is this "working correctly" because it is a "Windows" permission share?

 

[anodos]

It depends on the behavior you want. If an extended ACL is present, and if at least one of the 'special' ACEs is inheritable, then all permissions will be inherited from the directory you are copying the file to. If no special ACEs are inheritable, then the "create mask" value will be applied to set the posix mode on files that are created. Of course, this does not apply to when files are "moved" within a share. In this case, the file is just relinked.

 

[seanm]

So I've (again!) reread https://www.ixsystems.com/community/threads/methods-for-fine-tuning-samba-permissions.50739 to make sense of your words. :)

It doesn't describe what an "extended" ACL is... did you mean "explicit"?

I'm testing with a pretty vanilla share; after I copy the file Foo.txt and examine it from my FreeNAS:

ls -l
-rwxrwxr-x+ 1 builder wheel 0 Apr 8 17:13 Foo.txt

getfacl /mnt/ekur/Test2/Foo.txt
# file: /mnt/ekur/Test2/Foo.txt
# owner: builder
# group: wheel
owner@:rwxpDdaARWcCo-:------I:allow
group@:rwxpDdaARWcCo-:------I:allow
everyone@:r-x---a-R-c---:------I:allow

So, IIUC: all 3 of the 'special' ACEs are present and inheritable (the 'I'). There are no "explicit" ACEs, so this is a "trivial" ACL.

 

[anodos]

So I've (again!) reread https://www.ixsystems.com/community/threads/methods-for-fine-tuning-samba-permissions.50739 to make sense of your words. :)

It doesn't describe what an "extended" ACL is... did you mean "explicit"?

I'm testing with a pretty vanilla share; after I copy the file Foo.txt and examine it from my FreeNAS:

ls -l
-rwxrwxr-x+ 1 builder wheel 0 Apr 8 17:13 Foo.txt

getfacl /mnt/ekur/Test2/Foo.txt
# file: /mnt/ekur/Test2/Foo.txt
# owner: builder
# group: wheel
owner@:rwxpDdaARWcCo-:------I:allow
group@:rwxpDdaARWcCo-:------I:allow
everyone@:r-x---a-R-c---:------I:allow

So, IIUC: all 3 of the 'special' ACEs are present and inheritable (the 'I'). There are no "explicit" ACEs, so this is a "trivial" ACL.

An ACL is trivial if and only if the ACL can be entirely expressed by the posix mode. More specifically, for NFS4 ACLs, it is trivial if it is the same as the output of acl_strip_np(). You can convert it to a trivial ACL by executing setfacl -b /mnt/ekur/Test2. "I" indicates that the ACE was "Inherited" from the parent.

 

[seanm]

I should probably rewind and explain the root of my issue. On macOS, applications are actually directories that the UI shows as files <https://en.wikipedia.org/wiki/Bundle_(macOS)#macOS_application_bundles>. Within, there's a whole structure of files and folders that have particular permissions, ex:

Code:

ls -lR /Applications/TextEdit.app/
total 0
drwxr-xr-x  8 root  wheel  272 28 Jan  2018 Contents

/Applications/TextEdit.app//Contents:
total 0
-rw-r--r--   1 root  wheel  9535 28 Jan  2018 Info.plist
drwxr-xr-x   3 root  wheel   102  4 Jul  2018 MacOS
-rw-r--r--   1 root  wheel     8 28 Jan  2018 PkgInfo
drwxr-xr-x  48 root  wheel  1632  4 Jul  2018 Resources
drwxr-xr-x   3 root  wheel   102 28 Jan  2018 _CodeSignature
-rw-r--r--   1 root  wheel   508 28 Jan  2018 version.plist

If I copy TextEdit.app to, then back from FreeNAS, it comes back with different permissions. I'm not sure how much of a problem that is, but would like to avoid it.

Despite your helpful replies, I'm still not groking how to achieve this...

 

[fracai]

A workaround would be to zip the application bundle first. This is what I do when I'm manually archiving applications. You're probably not running the application over the share anyway.

 

[anodos]

A workaround would be to zip the application bundle first. This is what I do when I'm manually archiving applications. You're probably not running the application over the share anyway.

That is a good idea.
Rsync also will probably preserve the posix mode (depending on rsync flags and underlying ZFS ACL mode). cp -p will probably also achieve this as well, but zipping it up is most likely the best way to go about this.

 

[seanm]

fracai, thanks for your comment, but that's not an acceptable workaround. For one, yes, we sometimes do run things off the shares directly. For another, it seems quite reasonable to me that I should be able to copy something to/from non-destructively.

 

[fracai]

Fair enough. I'll second the rsync suggestion then. My standard is: "rsync -Pva <source> <destination>"
P is --partial (resumable) and --progress
v is verbose
a is "archive" and turns on things like preserving timestamps and permissions

 

[seanm]

cp -p will probably also achieve this as well

@anodos As per my first message, I was already trying cp -a (-a implies -p).

@fracai I tried "rsync -Pva", no luck. On my Mac:

-rw-r--r--@ 1 sean staff 186286 13 Sep 2018 test.txt

then I used rsync to copy to a Folder where I already did "setfacl -b /mnt/ekur/Test2/Folder". Viewed on FreeNAS (via ssh):

-rw-rw-rw-+ 1 sean wheel uarch 186286 Sep 13 2018 test.txt

then "rsync -Pva"ed back to my Mac:

-rw-rw-rw- 1 sean staff 186286 13 Sep 2018 test.txt

At least it has stopped adding the execute bit after doing the 'setfacl' thing. But it's still getting changed from 644 to 666.

Anyway, Joe Average office worker doesn't know how to use rsync, they can only barely manage Finder. :)


So I'd still be interested to learn how to configure things so that copying a file (with Finder) to and back from FreeNAS can preserve the POSIX mode. Thanks.

 

[KrisBee]

So I'd still be interested to learn how to configure things so that copying a file (with Finder) to and back from FreeNAS can preserve the POSIX mode. Thanks.

The flippant answer is to just use NFS shares.

It's no surprise that the FreeNAS focus for SMB shares is creating as close to 100% compatibility with Windows as possible and all that entails with respect to ACL/ACEs. Both linux & MacOs users have to give some thought to how best use SMB shares and deal with the prospect of potential mismatch between the permission/mode of data stored on FreeNAS and as seen when mounted by their linux or MacOS client.

In FN11.2-U3, selecting a share type of "Windows" when creating a dataset removes the permission grid from the "Edit Permission" UI, sets the relevant ACL dataset properties and it is given an extended ACL as seen by the "+" at the end of the permssion bits displayed by the ls command, e.g:

Code:

root@freenas:/mnt/NasPool # zfs get all NasPool/myshare | grep acl
NasPool/myshare  aclmode                 restricted              local
NasPool/myshare  aclinherit              passthrough             inherited from NasPool
root@freenas:/mnt/NasPool # ls -l
total 29
drwxr-xr-x  6 chris      chris      10 Apr 24 09:19 clb
drwxr-xr-x  3 root       wheel       3 Dec 21 09:20 home
drwxr-xr-x  6 root       wheel       6 Dec 21 09:52 myJails
drwxrwxr-x+ 2 chris      chris       3 Apr 27 08:49 myshare
drwxrwxr-x  2 syncthing  syncthing   2 Apr 24 20:02 syncdata
drwxr-xr-x  6 root       wheel       6 Jan  1 15:32 topdataset
drwxr-xr-x  2 root       wheel       2 Feb 28 10:08 VM
drwxrwxr-x+ 3 chris      chris       5 Apr 26 11:18 winshare1
drwxrwxr-x  4 chris      chris       8 Apr 26 22:29 winshare2
root@freenas:/mnt/NasPool #

As you don't want extended ACLs, you have to use the CLI to remove it, in this example setfacl -b /mnt/NAsPool/myshare

If you thought to avoid this by selecting the share type as UNIX and setting the desired unix permission on this dataset before creating a SMB share for it, there is a trap here for the unwary user. When using the create SMB share UI, beware the effect of the "default permissions" tick box. This get's you back the default situation above. Do not select create "default permissons" if you have previously removed the ACL on the dataset you wish to share.

After creating a share, check the output of testparm -s, in the Global Section the create and directory mask are set to 0666 & 0777 respectively. These are the permission/mode you see for data stored on FreeNAS which was copied over from your MacOS via a SMB share. But how are these seen when you mount the share in MacOs? I don't know about "finder", but check the man pages for mount_smbfs, isn't there both a "-f" and "-d" option where you can specify the file and directory mode? ( see: https://superuser.com/questions/1269386/why-can't-i-mount-shares-by-smb-since-high-sierra ) The linux equivalent of mount.cifs certainly has these options.

In linux you can do this:

Code:

root@linuxbox:/# mount -t cifs -o user=chris,uid=1000,gid=1000,file_mode=0644 //192.168.0.56/myshare /home/chris/CIFS
Password for chris@//192.168.0.56/myshare:  ********
root@linuxbox:/# su chris
chris@linuxbox:/$ cd  /home/chris/CIFS
chris@linuxbox:~/CIFS$ touch testfile
chris@linuxbox:~/CIFS$ mkdir testdir
chris@linuxbox:~/CIFS$ ls -l
total 1024
drwxr-xr-x 2 chris chris 0 Apr 27 09:36 testdir
-rw-r--r-- 1 chris chris 0 Apr 27 09:35 testfile
chris@linuxbox:~/CIFS$ 

This is stored on FreeNAS as:

Code:

root@freenas:/mnt/NasPool/myshare # ls -l
total 2
-rw-r--r--  1 root   wheel  0 Apr 27 08:49 .windows
drwxrwxrwx  2 chris  chris  2 Apr 27 09:36 testdir
-rw-rw-rw-  1 chris  chris  0 Apr 27 09:35 testfile
root@freenas:/mnt/NasPool/myshare #

If storing the data on FreeNAS with mode 0644 / 0755 is important, then you could on a per-share basis enforce a different create and directory mask to the "Global Section" by adding additional params to your SMB share definition, e.g:

Code:

create mask = 0644
directory mask = 0755
force create mode =  0644
force directory mode = 0755

Which can give you this:

Code:

root@linuxbox:/# mount -t cifs -o user=chris,uid=1000,gid=1000,file_mode=0644 //192.168.0.56/myshare /home/chris/CIFS
Password for chris@//192.168.0.56/myshare:  ********
root@linuxbox:/# su chris
chris@linuxbox:/$ cd /home/chris/CIFS
chris@linuxbox:~/CIFS$ ls -l
total 1024
drwxr-xr-x 2 chris chris 0 Apr 27 09:36 testdir
-rw-r--r-- 1 chris chris 0 Apr 27 09:35 testfile
chris@linuxbox:~/CIFS$ touch test2file
chris@linuxbox:~/CIFS$ mkdir test2dir
chris@linuxbox:~/CIFS$ ls -l
total 2048
drwxr-xr-x 2 chris chris 0 Apr 27 09:51 test2dir
-rw-r--r-- 1 chris chris 0 Apr 27 09:51 test2file
drwxr-xr-x 2 chris chris 0 Apr 27 09:36 testdir
-rw-r--r-- 1 chris chris 0 Apr 27 09:35 testfile
chris@linuxbox:~/CIFS$ 

And on FreeNAS:

Code:

root@freenas:/mnt/NasPool/myshare # ls -l
total 3
-rw-r--r--  1 root   wheel  0 Apr 27 08:49 .windows
drwxr-xr-x  2 chris  chris  2 Apr 27 09:51 test2dir
-rw-r--r--  1 chris  chris  0 Apr 27 09:51 test2file
drwxrwxrwx  2 chris  chris  2 Apr 27 09:36 testdir
-rw-rw-rw-  1 chris  chris  0 Apr 27 09:35 testfile
root@freenas:/mnt/NasPool/myshare #

 

[seanm]

The flippant answer is to just use NFS shares.

I only chose SMB because it is default on both macOS & Windows, which is 80% of my office. I've just searched the web about macOS & NFS, and it seems support and performance is not so good (though I have not tried).

As you don't want extended ACLs, you have to use the CLI to remove it...

I don't *not* want ACLs/ACEs, I just want the mode to be preserved when copying a file to and then back. The same way the file timestamp is preserved.

If you thought to avoid this by selecting the share type as UNIX and setting the desired unix permission on this dataset before creating a SMB share for it, there is a trap here for the unwary user...

I've also read in this forum that that's not really a supported config anyway.

After creating a share, check the output of testparm -s, in the Global Section the create and directory mask are set to 0666 & 0777 respectively. These are the permission/mode you see for data stored on FreeNAS which was copied over from your MacOS via a SMB share.

Thanks for that info.

But how are these seen when you mount the share in MacOs? I don't know about "finder", but check the man pages for mount_smbfs, isn't there both a "-f" and "-d" option where you can specify the file and directory mode? ( see: https://superuser.com/questions/1269386/why-can't-i-mount-shares-by-smb-since-high-sierra ) The linux equivalent of mount.cifs certainly has these options.

On macOS the man page also shows those flags, but as I said, many of my coworkers are GUI-only types. The Finder doesn't have any GUI options for those flags.

If storing the data on FreeNAS with mode 0644 / 0755 is important, then you could on a per-share basis enforce a different create and directory mask to the "Global Section" by adding additional params to your SMB share definition

That's great to know, thanks! But what I really want is for the mode to be preserved (regardless of its value) *per file*.

In my testing, things that FreeNAS preserves:
- file modification date
- colour label
- resource fork
- HFS type/creator code
- custom icon
- Finder comment
- other extended attributes

Things that it doesn't:
- file creation date
- file POSIX mode
- custom file ACEs

 

[seanm]

So I'll live with the fact that the posix mode can't be preserved, but I have a new/related problem:

- I create dataset Test4, share type = Windows, everything else default
- I edit Test4 permissions: ACL type = Windows, owner = nobody, group = FooGroup, applied recursively
- I create a new SMB share pointing to Test4, all settings default
- From a Mac I connect as user=sean (a member of FooGroup), I copy a single file to the share.
- I ssh as root to FreeNAS and:

Code:

root@freenas[/mnt/ekur/Test4]# ll
total 19
drwxrwxr-x+  2 nobody  FooGroup  uarch    5 May  3 11:49 ./
drwxr-xr-x  12 root    wheel              uarch   12 May  3 11:44 ../
-rwxrwxr-x+  1 sean    FooGroup  uarch 8196 May  3 11:49 .DS_Store*
-rwxrwxr-x+  1 nobody  FooGroup  uarch    0 May  3 11:44 .windows*
-rwxrwxr-x+  1 sean    FooGroup  uarch 2416 Apr 30 22:32 test.txt*

root@freenas[/mnt/ekur/Test4]# getfacl .
# file: .
# owner: nobody
# group: FooGroup
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:r-x---a-R-c---:fd-----:allow

- From a Win10 VM I connect as user=bar (a member of FooGroup), then right-click > Properties > Security. I see "Everyone" has read-only access and I remove that, since this share should be available only to employees in FooGroup.
- Now back on the FreeNAS shell I see:

Code:

root@freenas[/mnt/ekur/Test4]# ll
total 19
drwxrwx---+  2 nobody  FooGroup  uarch    5 May  3 11:49 ./
drwxr-xr-x  12 root    wheel              uarch   12 May  3 11:44 ../
----rwx---+  1 sean    FooGroup  uarch 8196 May  3 11:49 .DS_Store*
-rwxrwxr-x+  1 nobody  FooGroup  uarch    0 May  3 11:44 .windows*
----rwx---+  1 sean    FooGroup  uarch 2416 Apr 30 22:32 test.txt*

root@freenas[/mnt/ekur/Test4]# getfacl .
# file: .
# owner: nobody
# group: FooGroup
            owner@:rwxpDdaARWcCo-:fd-----:allow
            group@:rwxpDdaARWcCo-:fd-----:allow

Notice that test.txt changed from 775 to 070. In and of itself I can live with that. *But* the problem is that if I then copy test.txt from the share to a Mac the file ends up 070 on the Mac too, and the user is in the nonsense situation where he can open the file directly from the share but *not* open the file after copying it to his own computer.

Am I doing something wrong here? If so, what's the correct way to config SMB share permissions so that only employees in a group have read/write access and no one else has any access? Thanks.

 

[KrisBee]

what's the correct way to config SMB share permissions so that only employees in a group have read/write access and no one else has any access?

Do mean for exclusive use by a set of Windows users in group, or exclusive use by a set of MAC users in group, or ... ?

 

[sretalla]

Perhaps the important thing to think about here is that a copy operation takes the source file and creates a new file in the target location that gets the same binary content.

If you create a new blank file in the same place, does it get the same permissions? (yes... then everything works as expected).

It's typical in Windows (but works differently in some other OS cases I don't know so much about) that a move operation (not copy), takes the permissions of the source file and applies them to the target just before deleting the source file (even though the target file is also a newly created file in the target location).

If you don't like the way this works, you can use a tool that does copying or moving in a way that you prefer (or select)... like rsync (unix/linux/macOS), robocopy in windows... plenty of other options... but drag and drop are almost always going to end with what I mentioned.

So even if you copy the "same" file to a share and then copy it back to the same location, it may not get the same permissions in the original location that the original file had/has.

 

[seanm]

Do mean for exclusive use by a set of Windows users in group, or exclusive use by a set of MAC users in group, or ... ?

Not sure what you mean. All the user accounts are created on the FreeNAS (no LDAP/AD). I have a user account for every employee. Some employees use Mac, some Windows, some linux. *Most* use more than one OS, and need to access shares from any/all OSes.

My plan was to create 2 groups per share (again on FreeNAS, no LDAP/AD): one for read access, one for write access. So ex:

AccountingShare: read-only access to AccountingReaders group, r/w access to AccountingWriters group, no access for others
MarketingShare: read-only access to MarketingReaders group, r/w access to MarketingWriters group, no access for others

Then I can add/remove any employee (bob, alice, etc.) to any group as needed.

Is this a reasonable/typical setup?

 

[seanm]

I've just retested in 11.2-U4 what I wrote in post #15 above and the same occurs.

In fact, it seems changing permissions from Windows' right-click Properties > Securities alters the POSIX mode of all files that already exist on the share. Surely this is a bug? @anodos ?

 

[seanm]

I've created a jira ticket: https://jira.ixsystems.com/browse/NAS-101685