SMB share to Mac & Linux machines, no Windows

[melbow]

Hi, I'm looking to share a dataset from my FreeNAS 11.1 server to my Mac and Ubuntu machines, I currently have no Windows machines and don't plan to, at least for the foreseeable future.

From reading around a bit, I think an SMB share is my best option. I tried setting up a dataset with "share type Windows" and sharing this via SMB, and it works ok to mount and read/write normally from mac/linux, but I had problems rsync'ing to it*, presumably because "rsync -a" wants to preserve permissions and these are different to the Windows permissions on the share. This is a problem since generally I'd like to preserve my unix files' metadata and I'd like to use rsync. This link says that using sudo with rsync will work, but it sounds like a bad workaround (doesn't really tackle the problem of different permissions styles) and besides that I don't necessarily have the option of sudo for all users.

I also tried with "share type Unix" being shared with SMB. This seems to work fine (including rsync), but this forum thread and this docs comment say that it is not recommend. The caveats mentioned in the first (forum thread) link are not listed (I didn't want to resurrect an old thread to ask), but I believe it's due to Unix permissions not supporting Windows ACLs. My questions are: 1) Is this the only caveat? and 2) If so, am I'm right in thinking that this can never cause problems if I never use Windows?

Cheers!

Edit to add: *rsync error was: `rsync mkstemp operation not permitted`

 

[anodos]

Hi, I'm looking to share a dataset from my FreeNAS 11.1 server to my Mac and Ubuntu machines, I currently have no Windows machines and don't plan to, at least for the foreseeable future.

From reading around a bit, I think an SMB share is my best option. I tried setting up a dataset with "share type Windows" and sharing this via SMB, and it works ok to mount and read/write normally from mac/linux, but I had problems rsync'ing to it*, presumably because "rsync -a" wants to preserve permissions and these are different to the Windows permissions on the share. This is a problem since generally I'd like to preserve my unix files' metadata and I'd like to use rsync. This link says that using sudo with rsync will work, but it sounds like a bad workaround (doesn't really tackle the problem of different permissions styles) and besides that I don't necessarily have the option of sudo for all users.

I also tried with "share type Unix" being shared with SMB. This seems to work fine (including rsync), but this forum thread and this docs comment say that it is not recommend. The caveats mentioned in the first (forum thread) link are not listed (I didn't want to resurrect an old thread to ask), but I believe it's due to Unix permissions not supporting Windows ACLs. My questions are: 1) Is this the only caveat? and 2) If so, am I'm right in thinking that this can never cause problems if I never use Windows?

Cheers!

Edit to add: *rsync error was: `rsync mkstemp operation not permitted`

You can try with "unix" permissions type with a few caveats:

1) If you remove the zfsacl vfs module, there are some situations where Samba will try to set posix-style ACLs on files / dirs if you don't have zfsacl enabled. This fails with 'invalid parameter' because of the ACL branding mismatch (posix vs nfsv4).

2) If you choose to leave the zfsacl vfs module in place, you should define your share's permissions via explicit access control entries. For instance, if you want the group "smb_group" to have access to your share at /mnt/dozer/share, then setfacl -m g:smb_group:full_set:fd:allow /mnt/dozer/share. This will set the following ACE on the share:

Code:

# file: FINDER_TESTER/
# owner: 1001
# group: smb_group
   group:smb_group:rwxpDdaARWcCos:fd-----:allow
			owner@:rwxp--aARWcCos:-------:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:rwxp--a-R-c--s:-------:allow

Notice how the group:smb_group entry has DdAWCo and fd? Those permissions represent Delete|Delete Child|Write Attributes|Write Extended Attributes|Write Permissions|Change Owner. And fd represents "file inherit" and "directory inherit". Samba with zfsacl enabled will look at all of these bits to generate the security descriptor it presents to smb clients. In short, it defines your permissions. When you chmod a directory, it strips off most of these extra bits from owner@,group@, and everyone@ to form a conventional unix mode (it's more complicated than that, you should read the relevant rfcs for details if you're interested). You are generally safe if you go out of your want to not use these to define permissions for your share... but out of the box FreeNAS will grant owner and group "full control" rwxpDdaARWcCos:fd. Therein lies the problem. If people then chmod the directory or file, they'll cut off permissions that samba's using to define access to the share and access to the share's directories becomes undefined / inconsistent. This is one of the reasons why we set the aclmode to restricted on Samba shares. It prevents this operation from happening. See below:

Code:

root@cat_herder:/mnt/dozer # setfacl -m group@:full_set:fd:allow FINDER_TESTER/
root@cat_herder:/mnt/dozer # getfacl FINDER_TESTER/
# file: FINDER_TESTER/
# owner: 1001
# group: smb_group
   group:smb_group:rwxpDdaARWcCos:fd-----:allow
			owner@:rwxp--aARWcCos:-------:allow
			group@:rwxpDdaARWcCos:fd-----:allow
		 everyone@:rwxp--a-R-c--s:-------:allow
root@cat_herder:/mnt/dozer # chmod 777 FINDER_TESTER/
chmod: FINDER_TESTER/: Operation not permitted
root@cat_herder:/mnt/dozer # zfs set aclmode=passthrough dozer/FINDER_TESTER
root@cat_herder:/mnt/dozer # chmod 777 FINDER_TESTER/
root@cat_herder:/mnt/dozer # getfacl FINDER_TESTER/
# file: FINDER_TESTER/
# owner: 1001
# group: smb_group
   group:smb_group:rwxpDdaARWcCos:fd-----:allow
			owner@:rwxp--aARWcCos:-------:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:rwxp--a-R-c--s:-------:allow
root@cat_herder:/mnt/dozer #

Note how the chmod 777 actually removed permissions for group@, but the permissions for group:smb_group were unaffected. Hence my contention that if you define permissions using explicit ACEs, you should be more-or-less fine.

Anyway, this gets complicated quickly. Play around, test it, figure out what works for you, but if you break it you get to keep the pieces. ;)

 

[melbow]

Thanks for the detailed explanation - was exactly what I was looking for.

Certainly given me plenty to think about and experiment with!