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:
; 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:
; 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.
Comments (10)
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.
Posted by Andrew
|
April 7, 2010 8:51 AM
Posted on April 7, 2010 08:51
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
Posted by Andrew
|
April 23, 2010 1:32 PM
Posted on April 23, 2010 13:32
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.
Posted by Andrew
|
June 4, 2010 9:48 AM
Posted on June 4, 2010 09:48
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.
Posted by Andrew
|
June 4, 2010 11:47 AM
Posted on June 4, 2010 11:47
Thanks for posting this, finally I got my ACL problem solved.
http://superuser.com/questions/184191/files-on-smb-share-are-locked-and-some-apps-cant-touch-them/184274#184274
Posted by Sorin Sbarnea
|
September 3, 2010 7:11 AM
Posted on September 3, 2010 07:11
I was stuck with ACL, thanks!
Posted by SEO
|
September 18, 2010 6:28 AM
Posted on September 18, 2010 06:28
@Andrew
Your work around worked like a charm! Thanks SEO
Posted by SEO
|
September 18, 2010 6:29 AM
Posted on September 18, 2010 06:29
Hi Andrew, I have been trying to solve this problem as well for the last 4 months, so I appreciate the tip. Thanks :-)
Thomas
Posted by Thomas Eriksen
|
November 16, 2010 11:46 AM
Posted on November 16, 2010 11:46
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
Posted by Adam Bates
|
January 21, 2011 9:37 AM
Posted on January 21, 2011 09:37
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.
Posted by Screenshotzz
|
February 9, 2011 6:49 AM
Posted on February 9, 2011 06:49