CIFS permissions

[BlazeStar]

Now using 9.3

I started a thread sometimes during last year on that same issue but I can't seem to find it.

The conclusion was that it should be fixed in 9.3 so I let that aside.

But now running 9.3 it still doesn't work.

Here goes.

I have a dataset.
For this dataset I set the permissions, in FreeNAS GUI to :

• user = ME
• group = GROUP
• Apply mode CHECKED
• Permission type = WINDOWS
• Set recursively CHECKED

Then I created a CIFS share with apply default permissions.

Finally configure CIFS service with those options:
http://cl.ly/image/0w2j3l2y1Q0f
(don't mind the auxiliary parameters, even if I remove them, it doesn't matter)

Then start CIFS service.

I see the share, I can access it, then I want to tweak the permissions.

From what I've read on the forum, the preferred way to mess around with permissions is through the WINDOWS GUI and not shell (setfacl, etc.) or FreeNAS GUI

But there's the problem.

I go right click on the share, and go to the security tab.

First I see three things :

• Everyone
• My username (ME)
• And an object called "Unknown account" with a bunch of characters between parenthesis, which I guess is the group

First I remove everyone I don't even want to give out read privilege to everyone, but I've tried without doing that it doesn't matter.

Then let's say I want to add a group.
I would go into add, and then advanced.

But the only "objects" I can find are the usernames, when I launch a search.

The groups will never appear.

So I'm stuck with being only able to give permissions to users, and not groups, which really doesn't do the trick for me.

In the initial screen (in properties > security)
like I said there's ME and an unknown account with bunch of random characters between parenthesis, which I guess is the group.
If I keep that "unknown account" thing, and I modify the permissions, then if I go in the shell and do a "getfacl" I will be able to confirm my modification worked and now the group had correct permissions.
"getfacl" will also give me the correct group name, and not that unknown account crap.

So you could say it works.

BUT what if I want to add ANOTHER group and then set specific permissions for that one.

I have no idea how to do that and basically, that's what I need to do.

 

[BlazeStar]

So... no one is running into anything similar to this problem?

WTF is wrong with my install then :S

Any idea how to fix this?

 

[BlazeStar]

Guys why is nobody responding to this thread?

 

[anodos]

Sounds like your CIFS group mappings may have gotten blown up by a bad upgrade. Try fresh freenas install, auto-import your pool, and redo config from scratch. See if problem persists.

 

[BlazeStar]

Sounds like your CIFS group mappings may have gotten blown up by a bad upgrade. Try fresh freenas install, auto-import your pool, and redo config from scratch. See if problem persists.

Clean install of FreeNAS 9.3, then imported my config and the problem persists.

I'd REALLY want to avoid redoing my config if I could, given the number of users and shares I'd have to redo.

Anything I can try to fix / rebuild / clean the group mapping?

 

[SweetAndLow]

You can file a bug if you can show how it should work.

 

[BlazeStar]

You can file a bug if you can show how it should work.

I already did......... 5 months ago :(

https://bugs.freenas.org/issues/6723

 

[JJT211]

I really wish I could help but im pretty green in this area and in the process of learning the security of FreeNAS. I think your issue might be Windows related, hence, why you're possibly not getting many responses.

I have a FreeNAS system at home (im the only user), but at work I setup NAS4free out of an old PC and I was able to setup multiple groups using WinSCP with this tutorial. Im sure its not too different than with FreeNAS.
http://www.anotherwindowsblog.com/2...onfiguring-nas4free-on-a-windows-network.html

Hope it helps! GL!

 

[SweetAndLow]

Looks like you are going to get some one-on-one help. Let us know what the result of that is.

 

[BlazeStar]

Alright! All fixed now :)

Here's some info:

The issue was with the samba group mappings happening before the samba SID was being saved. Also, there was a point when the samba SID didn't used to get saved. I do not recall the exact version, but I want to say it was 9.2.1.8. So every time FreeNAS would get rebooted, a new SID was generated. We originally didn't even have group mappings, so this didn't matter. Once the group mappings were introduced, it mattered. So, when I looked at your group mappings, you had several different SID values. The "fix" was brute force, as follows:

service samba_server stop

rm -rf /var/db/samba4/*
rm -rf /var/etc/private*

service ix-pre-samba start
service samba_server start

At this point, is where the bug occurs. The newly created group mappings at this point had a consistent SID, however, it was not THE SID that was now correct ;-) So, to fix that:

net groupmap delete # this should blow away all mappings
service ix-pre-samba start # create config (and group mapping) with known SID

Ugly hack, however, I did just commit the fix that does the right thing. I hope this helps ;-)

 

[anodos]

Alright! All fixed now :)

Here's some info:

Thanks for posting this info. I was unsure of how to fix group mappings without starting a new FreeNAS config from scratch.

 

[stualden]

BlazeStar, just a point of clarification (I appear to be having a similar problem). You say

net groupmap delete # this should blow away all mappings

but when I do I get

Usage:

net groupmap delete {ntgroup=<string>|sid=<SID>}

Do I need to blow away each mapping individually, by SID?

EDIT: I think I figured it out - it should say "net groupmap cleanup." So for completeness, the whole process is

service samba_server stop

rm -rf /var/db/samba4/*
rm -rf /var/etc/private*

net groupmap cleanup # this should blow away all mappings
service ix-pre-samba start # create config (and group mapping) with known SID

service samba_server start

This fixed my problem, which was similar - the Unix groups were only showing up as SID strings on the Windows side - but I have been on 9.3 all along. Perhaps it was the last update? If I can reproduce the problem again I'll report it as a bug.

 

[MrToddsFriends]

service samba_server stop
rm -rf /var/db/samba4/*
rm -rf /var/etc/private*
net groupmap cleanup # this should blow away all mappings
service ix-pre-samba start # create config (and group mapping) with known SID
service samba_server start

I had the same problem and the sequence of commands shown here cured it.

My FreeNAS 9.3 update history for the last few weeks is

FreeNAS-9.3-STABLE-201504152200
FreeNAS-9.3-STABLE-201504292314
FreeNAS-9.3-STABLE-201505010007
FreeNAS-9.3-STABLE-201505040117

Perhaps FreeNAS-9.3-STABLE-201504292314 cased this problem, but this is pure speculation. At least some bug was found in this update and it was drawn back shortly after release.
https://forums.freenas.org/index.php?threads/9-3stable-april-29th-update-removing-itself.30566/


MrToddsFriends

 

[MrToddsFriends]

Argh, after reinstalling the Plex plugin and doing some preparation for storage the problems are back: Groups are not shown by name on client side (Windows 8.1 Explorer) and inability to configure permissions of shares on client side (neither user nor group names are recognized).

What I did in the meantime:
1) Installed PlexMediaServer 0.9.12.0.1071
2) Created a media dataset
3) Created a group plex (gid 972)
4) Created a user plex (uid 972)
5) Changed ownership of the media dataset to plex:plex
6) Created a CIFS share and a periodic snapshot task for the media dataset
Steps 2) to 6) of course outside of the plexmediaserver jail.

So at least in my case the problems have nothing to do with prior updates. I'll have to investigate this later.


MrToddsFriends

 

[FlynnVT]

Thanks. This just fixed my issue.

My 4+ year old ZFS share (unix permission type [==nobody as owner], open-ended guest account [==nobody] RW access via CIFS) stopped allowing modification of existing files. I can't pinpoint when it happened, but in the end I was on FreeNAS-9.3-STABLE-201505130355. Copying a new file worked OK, but once in place it would only read or delete. I don't care about access rights, so tried just about everything: switching to Windows permissions, setting those via a Windows client (access denied), reseating the "sane" defaults via setfacl (as per a 9.2-era bug report), "nt acl support = no" on the particular share etc.

In frustration I reinstalled FreeNAS from scratch. The latest ISO I had was FreeNAS-9.3-STABLE-201502110455.iso, so went with that. I set everything back up through the GUI and my share was back in action with correct permission behaviour. With one update I jumped directly to the same FreeNAS-9.3-STABLE-201505130355, at which point the ability to modify disappeared again. Frustrating!

The command sequence above restored the desired behavior on FreeNAS-9.3-STABLE-201505130355.

 

[FlynnVT]

This suddenly happened again today. I didn't update or even reboot, so can't imagine what might have triggered a loss of write permissions. Rerunning the same command sequence fixed things immediately.

 

[anodos]

Review your smb4.conf file. See if it has the "zfsacl" vfs object listed for your share. If so, file a bug report. That vfs object shouldn't be set on a dataset with Unix permission type.

 

[FlynnVT]

Thanks for that!
zfsacl is indeed set for all 3 shares, all of which are Unix permissions with open-ended RW permissions.
I recreated this system from scratch using 201502110455, so it's not a case of old entries in smb4.conf.

 

[anodos]

Thanks for that!
zfsacl is indeed set for all 3 shares, all of which are Unix permissions with open-ended RW permissions.
I recreated this system from scratch using 201502110455, so it's not a case of old entries in smb4.conf.

I presume that the zfsacl vfs object doesn't hopelessly break 'unix permissions' (we'd see more complaints and some bug reports if so), but it may contribute to some permissions woes in edge cases. I use Unix permissions on a few datasets and do not have problems with permissions.

Post a debug file. 'System' -> 'advanced' -> 'save debug'. I'll take a look through it when I have an opportunity.

 

[Brett Keller]

I presume that the zfsacl vfs object doesn't hopelessly break 'unix permissions' (we'd see more complaints and some bug reports if so), but it may contribute to some permissions woes in edge cases. I use Unix permissions on a few datasets and do not have problems with permissions.

Actually, it seems like that's exactly what happens: the zfsacl vfs object does break Unix permissions, at least partially.

I realize this thread is starting to get a bit old, but what FlynnVT was describing as his problem was almost exactly what I was finding on my CIFS shares with Unix permissions: users could create new files, but modifying existing ones proved troublesome. I was glad to see that I wasn't the only one having this problem, so I dug into it a bit more on a test system, and I was able to reliably reproduce serious permissions problems due to "zfsacl" being set on my CIFS share, which was using Unix permissions.

I filed bug report #11390, and much to my surprise I was told that Unix permissions are not supported with CIFS shares, period. The bug goes on to request a documentation change because I don't think this is made clear in the official docs.

I just wanted to share that critical bit of information right here because several people in this thread seem be under the impression (as I was until very recently) that Unix permissions ought to work fine with a CIFS share when, in fact, this is not the case, and the FreeNAS developers never intended the Unix/CIFS combination to be used at all. Knowing that would have saved me a bunch of headaches.