January 2010 Archives

Level II Oplocks and Snow Leopard Server Samba

| No Comments | No TrackBacks

If you do a testparm on your /etc/smb.conf file on Mac OS X Server 10.6, there's a good chance you'll see this message:

Level II oplocks can only be set if oplocks are also set.

You can read about "level2" or "level 2" opportunistic locking here in the official Samba HOWTO document (though it's written for v3.2 and Apple ships 3.0, I find it's almost entirely compatible and, in the least, quite informative). Here is what the document says,

Level2 Oplocks provides opportunistic locking for a file that will be treated as read only. Typically this is used on files that are read-only or on files that the client has no initial intention to write to at time of opening the file.

Level 2 oplocks appear to be something set to "true" or "on" by default. While Server Admin allows for enabling (plain old) oplocks and strict oplocks, there's no interface for setting level 2 oplocks off. But as the message indicates, it's effectively disabled without enabling locking in the first place.

If you do enable oplocks via Server Admin, and find the need to not have level 2 oplocks enabled too (for some odd reason — perhaps you're neurotically conscientious of your testparm output) you will need to specify this option explicitly on the share realm, not the global realm. 

Hand-edit your /etc/smb.conf file, following the convention indicated by Apple (that is, make your changes at the bottom of the conf file, using [My Sharepoint] instead of [global], setting

level2 oplocks = no [or false, if you prefer]

For example,

; Site-specific parameters can be added below this comment.
; END required configuration.

    realm = stanford.edu
    acl check permissions = no
    nt acl support = no 
    veto files = /Thumbs.db/.DS_Store/.TemporaryItems/TheVolumeSettingsFolder/TheFindByContentFolder/Temporary Items/Network Trash Folder/        

    path = /Shares/Projects     
    acl check permissions = no 
    nt acl support = no
    level2 oplocks = no

Remember that Apple recommends using oplocks only on shares accessed via SMB only.

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.
    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.

ACLs not being properly honored in Samba with XP clients

| 1 Comment | No TrackBacks

NB: Snow Leopard Server (10.6) handles directives on shares differently than with Leopard Server. Please also read this article if you are using Mac OS X Server 10.6 and Samba for new information on how to address the issues below.

Back in January 2008, I began to notice troublesome behavior with Windows clients connecting to my Mac OS X Server 10.5 fileserver.  When some Windows clients, particularly Windows XP users, try to connect to a share, they can create a folder but can't change the name of the folder from "New Folder". Also, they can drop a file on the share, but not change that name, either. This always happened when activity was performed at the root level of the network share, while subfolders behaved as expected. If the network share had 777 (rwxrwxrwx) at the root level, all worked well, which indicated a permissions issue, not so much a communication issue. BUt it's the ACLs that caused grief.  I posted this to the Mac OS X Server list hosted by Apple.

About this Archive

This page is an archive of entries from January 2010 listed from newest to oldest.

December 2009 is the previous archive.

February 2010 is the next archive.

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