Snow Leopard's Samba adds unwanted directives to shares

| 11 Comments | No TrackBacks
Update: Be sure to add the path of the share in your 10.6 edits suggested below.

There's an important behavioral difference between the version of Samba in Mac OS X Server 10.5 (Version 3.0.25b-apple) Snow Leopard's (Version 3.0.28a-apple) in the way it handles processing the /etc/smb.conf file and manages shares.

With 10.5 you could edit your /etc/smb.conf file include at least two directives in your custom [global] parameter set "acl check permissions = no" and "nt acl support = no" to address issues with locking and access. In some environments, these are very important to have, especially some Office documents and Windows XP clients.

With 10.6 however it appears you can't entirely rely on including these in your custom [global] section any longer, as recommended by Apple. You may need to append a share-specific parameter set with these two directives instead.

For example, at the end of /etc/smb.conf file:

; Site-specific parameters can be added below this comment.
; END required configuration.
[global]
    veto files = /Thumbs.db/.DS_Store/.TemporaryItems/TheVolumeSettingsFolder/TheFindByContentFolder/Temporary Items/Network Trash Folder/    

[Test Share]
    path = /Shares/Test Share
    acl check permissions = no
    nt acl support = no

I have a few ideas about what the problem might be.

Samba distributions include a command called testparm; here is the man page for it. It checks the integrity of an smb.conf file, much like apachectl configtest does with Apache.

Running the testparm command yields different output when executed on a 10.5 or 10.6 machine. In 10.5, you do not see your shares in the output; in 10.6, you do. The results give insight into how Apple changed the way network shares are configured and implemented in Samba. 

In the /etc/smb.conf file in 10.5, there's a usershare path = /var/samba/shares directive that hooks to a directory that contains discrete files for each sharepoint created using Server Admin. With 10.6, there's an include = /var/db/samba/smb.shares hook that instead points to a single file with all your shares, also as established by Server Admin. In 10.5, the testparm output doesn't show your shares; in 10.6, it does. What's going on?

The testparm command processes the /etc/smb.conf file the same way that smbd does, which is precisely the point. It processes not only the main conf file, but how smbd will see things after all the configuration hooks are taken into account. Interestingly, as 10.6 displays your shares, it shows acl check permissions = Yes  and nt acl support = Yes. Strange.

Well, it's not strange that they're set to Yes (that's the default). It's strange because its explicitness suggests these control parameters are associated with the [share] realm. If that's the case, attempting to negate these parameters in the [global] realm (as suggested here) won't be (or shouldn't be) effective. Directive values are concentric; if you have a value set in the [global] realm, it will be overridden by any identical but conflicting directive in the tighter [share] realm.

If my understanding is correct, the fix used with 10.5 needs to be further refined for 10.6. We can still negate parameters above by appending the same control parameter, but with a different value, further down the /etc/smb.conf file. Apple wants us to do this at the end, underneath the comments section (which tacitly implies they won't munge your hand edits in future updates). We just need the same directive, but this time not in the [global] realm, but in the [share] realm, something like this example, which has additions in both realms:

; Site-specific parameters can be added below this comment.
; END required configuration.
[global]
    veto files = /Thumbs.db/.DS_Store/.TemporaryItems/TheVolumeSettingsFolder/TheFindByContentFolder/Temporary Items/Network Trash Folder/

[Test Share]
    acl check permissions = no
    nt acl support = no


So what's up? Well, my theory is that the usershare path inclusion for defining shares (like in 10.5) meant that any user with access to the directory specified in the path could effectively create a share. If you could write to that directory, you could create a file to tell smbd to present a share on the network. That's the point of the usershare directive: to empower non-root users. 

But parameters like acl check permissions and nt acl support are very powerful and hugely affect filesystem access, so allowing non-root users to change all the variables on shares specified in the usershare path might be disallowed. In this case, the defaults for acl check permissions and nt acl support are Yes, and since I theorize you can't change these when also using usershare path, that effectively makes them global, overridable only by editing the restrictive/protected main smb.conf file.

In 10.6 though, Apple uses an include parameter instead to hook shares created by Server Admin. But wat remains unclear is why acl check permissions and nt acl support are still sticking closely to each share. Why does it take such an explicit un-doing of the default parameter? Defaults, when not explicit to the [share] realm, should also be un-doable at the [global] realm. So, to force Mac admins to make unique entries at the end of our /etc/smb.conf files seems the way to go for now. 

At least, this is my hypothesis at this point.


No TrackBacks

TrackBack URL: http://www.stanford.edu/group/macosxsig/cgi-bin/mt/mt-tb.cgi/89

11 Comments

Thanks for the info you've provided. It has helped us a lot. Have you still noticed this problem with 10.6.3. With or without your amendments in the smb.conf file? We suspect that even if we upgrade from 10.6.2 and add the amendments, we still will have the same problem. However we have to test further.

Having not yet done the upgrade to our servers to 10.6.3, and made the appends in the smb.conf file, the problem came up yet again for a few users (no pattern we can find on which users). We are now using a different workaround:
In Server Admin, click the server name (not any of its services), click Access > Services tab > on the left pane, select SMB > on the right pane, rather than have "Allow all users and groups", choose "Allow only users and groups below" and add your all encompassing security group.

I got the idea from:
http://discussions.apple.com/thread.jspa?threadID=2253773&tstart=1

My workaround threw in a small host of undesired complexities and unwanted restrictions, so we abandoned them after 10.6.3 got installed. 10.6.3 worked, but only for about 2 months, now we're once again in a bind where the amendments of the smb.conf don't work, and we're reluctant to use the workaround. Somehow there is a greater smb issue that needs to be resolved. It would also be nice if Apple's smb version was later than what now exists.

A less damaging workaround is to change the POSIX owner (defaulted at Server Admin) to the username. Then propagate permissions. Then you'll find if you change it back, it will then work again as well.

I was stuck with ACL, thanks!

@Andrew

Your work around worked like a charm! Thanks SEO

Hi Andrew, I have been trying to solve this problem as well for the last 4 months, so I appreciate the tip. Thanks :-)
Thomas

Andrew, I can't thank you enough for this post. I was having this issue for while & couldn't figure out a solution. I was almost ready to give up when I read this post. Thanks again for this invaluable resource. Seo Carlsbad

Thanks for the info you've provided. It has helped us a lot. Have you still noticed this problem with 10.6.3. With or without your amendments in the smb.conf file? We suspect that even if we upgrade from 10.6.2 and add the amendments, we still will have the same problem. However we have to test further to make sure our corporate team building courses application is up and running smoothly.

Cheers, this has been a great week as I am getting married at a fantastic wedding venues in United Kingdom. This in turn gives me the opportunity to purchase professional indemnity insurance just to be on the safe side.

Hi Andrew... Snow Leopard works on any Mac with an Intel processor with the added bonus of giving some hard drive space.

Leave a comment

About this Entry

This page contains a single entry by Noah Abrahamson published on January 14, 2010 2:53 PM.

ACLs not being properly honored in Samba with XP clients was the previous entry in this blog.

Level II Oplocks and Snow Leopard Server Samba is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.