I need a better fix for my samba guest permissions problems. I am running FreeNAS-8.2.0-RELEASE-p1-x64 (r11950). I'll explain the "fix" later, but first the problem...
I have been getting mixed results with setting up a samba share to allow full control to guest. Specifically, here are a couple of examples, tested from a Windows 7 box as the client. To understand what I am describing, you'll need to know that I have 2 shares, one hacked and one not. Both shares have the same path value in smb.conf (full details below). So, I can access the same files via a way that works and a way that does not work. The way that works is a ridiculous ugly hack and needs a better fix. So, here are a couple of examples:
One additional difference that I have noticed between the hacked share and the non-working share is that whenever I check the folder security on the security tab of the folder properties, the group "Everyone" has a checkmark in the "Deny" column of the "Special Permissions". The hacked share does not have this. That's kinda difficult to describe. So, I have attached a screenshot.
Here's my hack. In my configuration for my CIFS Share (Sharing->Windows (CIFS) Shares->my share), in the Advanced Mode, for the "Auxiliary Parameters", I entered a completely new stanza to create a samba share with the directives that I want. I have a attached a screenshot of that, too.
Not only does this ugly hack work, it's diagnostic because I can compare the directives between the hacked share and the non-working share to see what may be different. As it turns out, it's not a matter of the non-working share missing anything, it seems to have more to do with the non-working share containing a few directives that I don't understand and that I can't seem to eliminate.
Here's the non-working stanza from smb.conf:
Here's the hacked stanza (this matches the screenshot of the Auxillary parameters):
Incidentally, some of these directives appear to be hard coded in "/conf/base/etc/rc.d/ix-samba". Therefore, it appears to me that these directives cannot be controlled via the web interface. Furthermore, I suspect they may be required for zfs (which I am new to), which makes me nervous about circumventing these:
From "/conf/base/etc/rc.d/ix-samba":
Finally, the Unix permissions derived via ls -l on the command line show guest:guest for the user and group ownership for the volume (/mnt/vol_0) as well as the subdirectories below the mount point. The directory permissions for the volume are 755.
So, can anyone straighten me out on this? Am I missing some important concept in the way samba relates to volumes, datasets or zfs?
I have been getting mixed results with setting up a samba share to allow full control to guest. Specifically, here are a couple of examples, tested from a Windows 7 box as the client. To understand what I am describing, you'll need to know that I have 2 shares, one hacked and one not. Both shares have the same path value in smb.conf (full details below). So, I can access the same files via a way that works and a way that does not work. The way that works is a ridiculous ugly hack and needs a better fix. So, here are a couple of examples:
- Within Windows Explorer, I can navigate to my FreeNAS share and click "New Folder". The "New Folder" is created and remains selected while it is waiting for me to name it. But, I am denied access when I try to save the new name by pressing <Enter>. The folder is then created as "Untitled Folder".
- I can navigate into this new untitled folder via Windows Explorer on the non-working share and create an empty text file, modify it and save it, no problem.
- When I use Windows Explorer to navigate to my non-working share and right click on it in Windows Explorer on Windows 7, then select properties->security, I get a message about permissions being "incorrectly ordered". On my hacked share, I do not get this message.
- If I try to delete this Untitled Folder via the non-working share, I cannot delete it. Windows gives an error message stating that "Folder Access is Denied" and "You need permission to perform this action". However, if I go via my hacked share, I can delete it.
One additional difference that I have noticed between the hacked share and the non-working share is that whenever I check the folder security on the security tab of the folder properties, the group "Everyone" has a checkmark in the "Deny" column of the "Special Permissions". The hacked share does not have this. That's kinda difficult to describe. So, I have attached a screenshot.

Here's my hack. In my configuration for my CIFS Share (Sharing->Windows (CIFS) Shares->my share), in the Advanced Mode, for the "Auxiliary Parameters", I entered a completely new stanza to create a samba share with the directives that I want. I have a attached a screenshot of that, too.

Not only does this ugly hack work, it's diagnostic because I can compare the directives between the hacked share and the non-working share to see what may be different. As it turns out, it's not a matter of the non-working share missing anything, it seems to have more to do with the non-working share containing a few directives that I don't understand and that I can't seem to eliminate.
Here's the non-working stanza from smb.conf:
[FreeNAS-old]
path = /mnt/vol_0
printable = no
veto files = /.snap/.windows/.zfs/
comment = Top FreeNAS Volume
writeable = yes
browseable = yes
inherit owner = no
inherit permissions = no
vfs objects = zfsacl
hosts allow = 10.0.0.0/24
guest ok = no
inherit acls = Yes
map archive = No
map readonly = no
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
printable = no
veto files = /.snap/.windows/.zfs/
comment = Top FreeNAS Volume
writeable = yes
browseable = yes
inherit owner = no
inherit permissions = no
vfs objects = zfsacl
hosts allow = 10.0.0.0/24
guest ok = no
inherit acls = Yes
map archive = No
map readonly = no
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
Here's the hacked stanza (this matches the screenshot of the Auxillary parameters):
[FreeNAS]
path = /mnt/vol_0
comment = FreeNAS
guest ok = yes
writeable = yes
browseable = yes
create mode = 666
directory mode = 777
force user = guest
force group = guest
comment = FreeNAS
guest ok = yes
writeable = yes
browseable = yes
create mode = 666
directory mode = 777
force user = guest
force group = guest
Incidentally, some of these directives appear to be hard coded in "/conf/base/etc/rc.d/ix-samba". Therefore, it appears to me that these directives cannot be controlled via the web interface. Furthermore, I suspect they may be required for zfs (which I am new to), which makes me nervous about circumventing these:
From "/conf/base/etc/rc.d/ix-samba":
cat<<-EOF
inherit acls = Yes
map archive = No
map readonly = no
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
EOF
inherit acls = Yes
map archive = No
map readonly = no
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
EOF
Finally, the Unix permissions derived via ls -l on the command line show guest:guest for the user and group ownership for the volume (/mnt/vol_0) as well as the subdirectories below the mount point. The directory permissions for the volume are 755.
So, can anyone straighten me out on this? Am I missing some important concept in the way samba relates to volumes, datasets or zfs?