On FreeNas what is the difference between the "Permission Type" and the "Share Type" setting?
I have looked for the same and the information was very limited.
So I did my own experiments and found that all this comes down to permissions applied to the root of the dataset.
If you set the share type to UNIX
, nothing special happens. A new dataset is created and it is mounted where you expect it to be, with the typical 755 permission set for directories.
[root@freenas] /mnt/data1/unix# ll
total 3
drwxr-xr-x 2 root wheel 2 Oct 27 08:06 ./
drwxr-xr-x 8 root wheel 8 Oct 27 08:06 ../
[root@freenas] /mnt/data1/unix# getfacl .
# file: .
# owner: root
# group: wheel
owner@:rwxp--aARWcCos:------:allow
group@:r-x---a-R-c--s:------:allow
everyone@:r-x---a-R-c--s:------:allow
But if you select Windows
, a few things will happen:
- a
.windows
file is created at the root of the dataset. I'm just guessing this is just to help FreeNAS GUI track what kind of permission scheme was set here. - a NFSv4 ACL is added to the root of the dataset.
Below you'll find how the permissions were applied to a Windows
dataset.
[root@freenas] /mnt/data1/windows# ll
total 3
drwxrwxr-x+ 2 root wheel 3 Oct 27 08:06 ./
drwxr-xr-x 8 root wheel 8 Oct 27 08:06 ../
-rw-r--r-- 1 root wheel 0 Oct 27 08:06 .windows
Noticed that little +
sign for the .
directory? It means that ACLs are set for particular resource...
[root@freenas] /mnt/data1/windows# getfacl .
# file: .
# owner: root
# group: wheel
owner@:rwxpDdaARWcCos:fd----:allow
group@:rwxpDdaARWcCos:fd----:allow
everyone@:r-x---a-R-c---:fd----:allow
And that's all. In both places in the UI the meaning is the same.
However, once the permissions are set, FreeNAS GUI does not work perfectly when you'd like to change the type of the permissions (exp. it won't execute setfacl -b
when changing from Windows
to UNIX
scheme) etc.
So it all depends what you want to achieve. But I personally like the NFSv4 ACL and recommend setting the Windows
type at all times. It is a really sane by default, will use inheritance and works well through CIFS and from local shell. I haven't tested how it behaves when accessing using NFS mount.