OK, I thought that was handled by Samba/FreeNAS... I learned something. I must admit that I don't really understand windows permissions or got into nix permissions much beyond the standard rwxrwxrwx. Is this likely to make FreeNAS play nicely with both Nix and Windows sharing the same dataset?
I guess they will never be directly compatible because of the very different permission/ACL systems on Unix/Windows -- or do I have that wrong as well?
I may have been reading too much into this but I had the feeling you were curious about Windows permissions compatibility of FreeNAS, or maybe I was just looking for an excuse to tinker and write a long-ass post, so I took it upon myself to do a test of it's OOB compatibility in a domain environment.
I realize you were meaning ZFS permissions in Windows which is a lot more nuanced, but I'll try and cover that as best I can towards the end, while admitting I don't know a whole lot about it. I believe it is done through Samba using some convoluted SID-->NFSv4-->POSIX ACL translation, but the real questions most people want answered is "does it work?" and how well, what's broken and what's not, etc...
For reference, I'm writing this from a laptop running Windows LTSC 2019, I have a small ESXi 6.7U1 homelab with two hosts and VCSA, and two of the VMs are Server 2012R2 domain controllers with AD Unix attributes (which has been depreciated - grr)
Honestly I haven't used FreeNAS in about a year, I had switched to lighter OS that are not appliance-style so I could do more on-the-fly configuration (I got annoyed that I had to do everything from the web UI for changes to be persistent, but I caveat that by saying that's a GOOD thing for most people). All in all, it's a great concept for bringing top-flight FS features to more people and it looks like it's progressing really quickly. I can tell after 30 min of using it that the AD domain compatibility has grown by leaps and bounds.
I think to your first point Unix permissions are the 'standard' chmod 0-7 scale 3 (or 4 if you're getting deep into it) column permissions (e.g. 750 = root write, user/group read/execute, everyone else nothing). As long as you remember which column is for which user level, that's all you really need to know. Ownership is attributed to the user:group (that's the second column) using chown. If you're in that group or that user, that second column applies to you, unless you're root - that's the first column. If you're neither, that's the 3rd column for everybody else. There's a bit more to it, of course, but it's fundamentally very straight-forward and simple (which is refreshing).
For Windows, you have security identifiers or 'SIDs'. Like Unix, a bunch of system accounts are present by default and have common SIDs and names which like the Unix names + UIDs are common across most systems. If you want to read more about that, I turned up this interesting document:
https://docs.microsoft.com/en-us/windows/desktop/secauthz/well-known-sids
There's also relative IDs, RIDs, which I *believe* are basically analogous to Unix groups but can encompass more things than just groups, like security designations (don't ask me what the difference is). But essentially they're just a way to make certain things apply to more than one SID, like groups for users.
Anyway, to see how the compatibility is out of the box, I set up a FreeNAS VM. All I've done so far is run through the wizard (had to do it in the legacy web UI since I couldn't find it in the new UI, but it looks nice nonetheless), connect to the domain, make a pool and make an SMB share. So far it looks good, here's my
# getent passwd:
Code:
WEBTOOL\administrator:*:20500:20513::/home/WEBTOOL/administrator:/bin/sh
WEBTOOL\guest:*:20501:20513::/home/WEBTOOL/guest:/bin/sh
WEBTOOL\krbtgt:*:20502:20513::/home/WEBTOOL/krbtgt:/bin/sh
WEBTOOL\avery:*:21108:20513::/home/WEBTOOL/avery:/bin/sh
WEBTOOL\sharepointadmin:*:27109:20513::/home/WEBTOOL/sharepointadmin:/bin/sh
WEBTOOL\kelley:*:27606:20513::/home/WEBTOOL/kelley:/bin/sh
You can see at the bottom that the domain accounts show up. That is great because earlier iterations of FreeNAS had issues getting domain users through getent (I remember struggling for days to try and get it to work previously). Same goes for the groups,
# getent group:
Code:
WEBTOOL\winrmremotewmiusers__:x:21000
WEBTOOL\domain computers:x:20515
WEBTOOL\domain controllers:x:20516
WEBTOOL\schema admins:x:20518
WEBTOOL\enterprise admins:x:20519
WEBTOOL\cert publishers:x:20517
WEBTOOL\domain admins:x:20512
WEBTOOL\domain users:x:20513
WEBTOOL\domain guests:x:20514
WEBTOOL\group policy creator owners:x:20520
WEBTOOL\ras and ias servers:x:20553
WEBTOOL\allowed rodc password replication group:x:20571
WEBTOOL\denied rodc password replication group:x:20572
WEBTOOL\read-only domain controllers:x:20521
WEBTOOL\enterprise read-only domain controllers:x:20498
WEBTOOL\cloneable domain controllers:x:20522
WEBTOOL\protected users:x:20525
WEBTOOL\dnsadmins:x:21102
WEBTOOL\dnsupdateproxy:x:21103
WEBTOOL\dhcp users:x:21104
WEBTOOL\dhcp administrators:x:21105
WEBTOOL\sudoers:x:21109
WEBTOOL\vcsa administrators:x:21112
WEBTOOL\libvirt:x:24603
WEBTOOL\jumpcloud:x:27607
All this so far is Samba compatibility - with some good back-end stuff set up by default like
libgssapi krb5-sssd, etc. for domain support. Note as of writing FreeNAS is using
Samba49, here's the default AD-connected
# testparm:
Code:
root@freenas[~]# samba --version
Version 4.9.4
root@freenas[~]# testparm
Registered MSG_REQ_POOL_USAGE
Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
Load smb config files from /usr/local/etc/smb4.conf
Processing section "[tank]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions
# Global parameters
[global]
allow trusted domains = No
client ldap sasl wrapping = plain
deadtime = 15
disable spoolss = Yes
dns proxy = No
domain master = No
dos charset = CP437
hostname lookups = Yes
kernel change notify = No
lm announce = Yes
load printers = No
local master = No
logging = file
map to guest = Bad User
max log size = 51200
max open files = 116768
nsupdate command = /usr/local/bin/samba-nsupdate -g
obey pam restrictions = Yes
preferred master = No
printcap name = /dev/null
realm = WEBTOOL.SPACE
security = ADS
server min protocol = SMB2_02
server role = member server
server string = FreeNAS Server
template shell = /bin/sh
time server = Yes
winbind cache time = 7200
winbind enum groups = Yes
winbind enum users = Yes
winbind offline logon = Yes
winbind refresh tickets = Yes
workgroup = WEBTOOL
idmap config webtool: range = 20000-90000000
idmap config webtool: backend = rid
idmap config *: range = 90000001-100000000
idmap config * : backend = tdb
acl allow execute always = Yes
create mask = 0666
directory mask = 0777
directory name cache size = 0
dos filemode = Yes
strict locking = No
[tank]
guest ok = Yes
path = "/mnt/tank/tank"
read only = No
veto files = /.snapshot/.windows/.mac/.zfs/
vfs objects = zfs_space zfsacl streams_xattr
zfsacl:acesort = dontcare
nfs4:chown = true
nfs4:acedup = merge
nfs4:mode = special
I delved into these vfs objects a bit to flesh this out and try and understand what Samba is doing for a Windows compatibility layer with ZFS.
zfs_space is for listing free space in Windows client, zfsacl = posix acl compatibility for zfs:
https://www.samba.org/samba/docs/current/man-html/vfs_zfsacl.8.html streams_xattr = alternative streams, I believe this is a workaround for parallel data transfer while using POSIX ACLs:
https://www.samba.org/samba/docs/current/man-html/vfs_streams_xattr.8.html
So what about compatibility from Windows, though?
Well, I tried connecting to the SMB share of the pool using MMC shared folders snap-in, but that's a no-go, at least without some additional configuring.
Here I am accessing the shared folders snap-in, which looks like it's working fine...
but check out what happens when I try and add a user to the share:
I'm guessing it has something to do with Unix perms, so here's what they are:
Code:
root@freenas[/mnt]# ls -la
total 6
drwxr-xr-x 3 root wheel 128 Apr 12 23:30 .
drwxr-xr-x 21 root wheel 28 Apr 12 23:33 ..
-rw-r--r-- 1 root wheel 5 Apr 12 23:03 md_size
drwxr-xr-x 3 root wheel 3 Apr 12 23:30 tank
Let's try and just open that up and see what happens: ohp, can't #chmod -R 777 the share.
I tried to delete the share and the corresponding dataset
tank/tank but I got
cannot unmount '/mnt/tank/tank': Device busy Unsupported share protocol: 1
Welp, it's late and I'm tired. I'll finish this post up later. But so far it looks like there's some issues I'm going to have to delve deep to tackle.
