Crazy Fix for Samba Guest Permissions

Status
Not open for further replies.

backdoc

Dabbler
Joined
Aug 27, 2012
Messages
22
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:

  1. 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".
  2. 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.
  3. 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.
  4. 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.

FreeNas_permissions.jpg

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.

hack.jpg

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​

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​

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

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?
 

backdoc

Dabbler
Joined
Aug 27, 2012
Messages
22
And, suddenly....it's not working for me anymore. It seems to work one moment and not the next. I guess I could give up and go with user authentication, but I really want to get guest access working.
 
Status
Not open for further replies.
Top