Configuring a CIFS share with Unix ACLs to work with Windows

[aaronadams]

Hi, just a quick question from a new FreeNAS user.

I'm configuring a share for an office full of Macs; however, they still have one stray Windows PC that also needs access to the share.

I can't seem to figure out how to get the Windows machine to play nice. It seems like no matter what I do, the Windows machine doesn't understand that it's allowed to modify files – even though it understands that it can create them!

Dataset permissions:

• Owner: nobody:allstaff
• Mode: 770 (though I've tried 777 to no avail)
• Type of ACL: Unix

CIFS settings:

• File mask: default (0666)
• Directory mask: default (0777)

CIFS share settings:

• Inherit owner: yes (have also tried no)
• Inherit permissions: yes (have also tried no)
• Inherit ACLs: yes (have also tried no)

When looking at permissions, it looks like Windows is picking up the actual raw Unix permissions (nobody:allstaff), rather than them being "mapped" to my CIFS user the way they are on OS X (where I see files with 700 permissions owned by Aaron:staff).

If I turn off, say, inherit owner and inherit permissions, then looking at a file created by another user, the Windows machine understands that the owner and group have read/write, but it doesn't understand that it's a member of the group.

Ideally this would work like it does in OS X; when I connected to the volume, it would just tell me I'm the owner of all of the files, and would tell me I could edit the ones I could edit. Instead it seems like CIFS is trying really hard to allow Windows to view the permissions, which is just causing problems.

Should I really switch to a Windows ACL just for one Windows machine?

 

[aaronadams]

…Just a note that I've now tried switching to Windows ACLs as well, but every time the Mac user writes to the file, the Windows user loses the ability to modify it.

I will take any recommendation that will support this dead simple environment:

• Mixed OS environment:
  • 10 × OS X 10.9
  • 2 × OS X 10.6
  • 1 × Windows 7 Home Premium
• Shared datasets
  • All users (with access to a share) can read/write all files on the share

I would prefer to avoid AFP, as it's a dead-end protocol. And I assume that sticking to CIFS makes more sense than a switch to NFS.

The machine is a brand new FreeNAS Mini:

• Intel Atom C2750 2.40GHz
• 16 GB ECC RAM
• 4 × 3 TB WD Red
• 4 × gigabit ethernet in LACP aggregation

I'd like to balance performance considerations against ease of setup and maintenance.

Any help is much appreciated, and thank you!

 

[cyberjock]

Should I really switch to a Windows ACL just for one Windows machine?

Short answer: Yes

Long answer: Y-E-S

 

[aaronadams]

See the second post. I tried that without luck.

 

[ShmUDE]

…Just a note that I've now tried switching to Windows ACLs as well, but every time the Mac user writes to the file, the Windows user loses the ability to modify it.

this is where im at right now. A single mac on the network will create a folder in a share and it will only allow that mac user to write to it. If a windows machine does it, it has the proper permissions. Ive tried unchecking Unix Extensions in the CIFS config and that didn't help after stopping/starting the service.

 

[aaronadams]

I've been down a much longer path now, and I still haven't found a working solution – although I recently thought I had it working, it came apart for reasons I was unable to determine.

I neither have nor want Active Directory services; I am trying to implement simple username-based CIFS/SMB sharing for a network of 9 Macs and 1 Windows PC. I also want to control access to each share; for simplicity's sake, let's say we have "allstaff" and "somestaff" shares, and that the users in question should only be able to access the allstaff share.

Here's what I expected would work:

• Owner: root:allstaff (or root:somestaff)
• Mode: 770
• ACL: Unix
• Inherit owner, permissions, and ACLs
• Each user a member of allstaff

When the Macs log into a CIFS share, this works exactly as expected. It appears that some "smart" permission transformation occurs; files owned by root:allstaff appear to my user to be owned by Aaron:wheel, which is exactly what I want.

The same thing doesn't happen on Windows, however; Windows sees the actual Unix owner/group for each file, and because it doesn't understand that it's authenticated to the NAS as a member of the allstaff group, the Windows user is left without write permissions.

I tried using Samba's username map functionality, and I swear that for a moment this worked; I created a "nasuser" user, changed ownership of all files to nasuser:allstaff, created sambausers.map containing "nasuser = Company" (the Windows user is named Company), and added the "username map" directive to the Samba config.

At first, I swear Windows picked this up and saw itself as the owner of the files, and everything worked for a moment!

I'm not sure what changed, but this is no longer working – I don't know if it has something to do with my moving the username map file to /root/sambausers.map to survive reboots, but Samba doesn't complain about its configuration, so I assume the problem is elsewhere. (Maybe this would be the point where Windows ACLs would come into play? Maybe "username map" only works on Windows ACL entries, and I unknowingly had some Windows ACL entries in there at the time?)

As best as I can tell, and please correct me if I'm wrong on either of these points:

• When a Windows (or Mac) user attempts to connect to a share, whether or not they can connect is determined by the permissions of the Unix user account with which they are authenticating, and not by ACLs.
• When a Windows user attempts to access a file, its permissions are determined by Windows ACLs; in the absence of (or in addition to?) Windows ACLs, the Unix permissions (or ACLs?) are used.

So, to get what I'm going for, a few possibilities, none seeming ideal or robust:

• I could possibly use the "net groupmap add" command to just map the Windows built-in "Users" group to my "allstaff" and "somestaff" groups – if my first assumption is correct, the Unix permissions would still keep non-members of "somestaff" out of the somestaff share – but functionality here seems like it would be undefined at best.
• I could change the owner of all of my files to "nasuser" and use Samba's "username map" directive to map my Windows user to the Unix nasuser.
  • Since there is no domain against which we are authenticating, the mapping occurs before authentication – so I guess we should authenticate using our Windows username?
  • Again, functionality here seems like it would be undefined – if I'm mapping my user to Unix nasuser, and that user owns shares I shouldn't be able to access, would I get access? Would that change in the future?
• I could switch to Windows ACLs and add entries, but how the heck do I indicate user Company on Company-PC in an ACL entry? Or do I create the ACL entry using the local user, and then use Samba's "username map"? Or do I create the ACL entry using the "allstaff" group, and then use "net groupmap add"? And if I do one of those two things, then why didn't I just stick with the Unix ACLs in the first place?

So, yeah. I'm feeling completely stuck here. This reallyfeels like it ought to be easier than it is!

Any snark-less assistance at all would be greatly appreciated, with many thanks.

 

[aaronadams]

…I guess I can't edit my own thread title, but "Configuring CIFS shares for Windows + Mac without directory services" probably better describes my question now, because I guess that's really what this is; without directory services, I just cannot figure out how to indicate to a Windows machine what its permissions should be.

 

[aaronadams]

I figured it out – no thanks to you lot ;)

First, I upgraded to the freshly released FreeNAS 9.2.1.6; this probably wasn't completely necessary, but it changes up a lot of the settings dialogs around CIFS to make them a bit simpler and harder to screw up.

Next, I created datasets, type "Windows". Don't be unduly afraid of this; they aren't actually NTFS ACLs like you might expect from such a setting! It really just sets some sane, Windows-friendly defaults on the UNIX ACLs that make Windows work.

Then, I created CIFS shares, and thanks to this Samba documentation, under the Advanced settings for each individual CIFS share, I went ahead and indicated which user groups should be able to connect to the share:

Code:

valid users = @allstaff

Finally, I dropped down to a terminal and issued a couple of setfacl commands to ensure everyone has read/write access (and an extra command to make sure wheel retains full control even if a future group inheritance bug pops up). Something like this, although I don't have access to the FreeNAS box right now, so this is from memory:

Code:

setfacl -m everyone@:modify_set:fd:allow share_folder
setfacl -m g:wheel:full_set:fd:allow share_folder

That's it! The files are owned by whoever creates them, but it doesn't matter; the group is wheel, but it doesn't matter; all that matters is that "everyone" has read/write, but only members of specific groups are allowed to connect to the share at all.

 

[ShmUDE]

i'll give a quick rundown on my issue/fix because its similar but yet different.

Im using Directory Services for my user accounts and have 99% windows computers. We do have a mac used for graphics and web work. I started having permissions issues when the mac would create files/folders and the windows users couldn't write to them, just read. The mac was connecting via SMB and was making up its own permissions. I switched to AFP and was still having the same issue with permissions until i found the little check box in the AFP share settings that turns off unix privileges (AFP3 Unix Privs:). Once i uncheck that, all files that the mac created had the correct permissions that the windows machine could read/write to.

I also switched to AFP because we were having issues with Photoshop PSD files not being able to be saved across the network and it would just hang photoshop and we would have to force close it. Moving the file to the local machine would fix the problem but thats not a viable solution. I found lots of people having the same issue and Adobe says that working off a USB or Network share isn't supported (dumb). Switching to AFP allowed me to save those files again. This was photoshop CS5 for what its worth.

and i might have found a bug with those .psd files. I can copy one to a share, open it, make a change and save it without problem. If i dont close the image and make another change and hit save it will delete the file off the share and photoshop will error out and say that it doesn't exist. I can replicate it on multiple freenas boxes.

 

[aaronadams]

It's probably worth noting that AFP is a "dead" technology; Apple themselves have abandoned it in favour of SMB2.

For what it's worth, if you move your Mac to OS X 10.9.2+, I'm willing to bet all of your SMB2 problems will go away; here at another company I work for, we have half Macs and half Windows PCs; we'd long had issues, and swtiching to 10.9.2 + SMB2 was the day all of those problems magically went away.

Still, good to know there are solutions! Even if the FreeNAS documentation is less than forthcoming with them.

 

[ShmUDE]

the problem is ive tested it on my newer laptop running mavericks and its still an issue. The mac pro is on 10.6 and she is dead set on not upgrading.

 

[cyberjock]

aaronadams-

The reason why it's not forthcoming is because Samba4 isn't very well documented. In fact I found out that if you authenticate as "root" it gives you full access to everything on the share, even if "root" shouldn't have permissions. Cool huh?

Anyway I'm writing up a permissions guide for TrueNAS and FreeNAS users and I will incorporate a little bit of your feedback into it. So thanks for posting what worked for you.

 

[J-NAS]

aaronadams-

The reason why it's not forthcoming is because Samba4 isn't very well documented. In fact I found out that if you authenticate as "root" it gives you full access to everything on the share, even if "root" shouldn't have permissions. Cool huh?

Anyway I'm writing up a permissions guide for TrueNAS and FreeNAS users and I will incorporate a little bit of your feedback into it. So thanks for posting what worked for you.

@cyberjock Can I assume when you are finished the permissions guide you will add it to your .sig? I found your other presentation very helpful--thank you. I look forward to your new guide.

 

[cyberjock]

Yes. But the permissions guide is on a suspension for the time being for a few reasons. It will get done, it's just not a priority at the moment. There's also a few things to hammer out.