samba - Mar 2007 - Need some explanation on Samba/NFS locks handle

Hi there,

We are thinking about sharing same files:
- OS2/Win clients with Samba
- Linux clients with NFS.
So, the same files would be shared by 2 different protocols.

Looking at the open.c samba code, there seems to be no check / no error 
(sharing violation) returned to the smb client when the file is already 
locked by an NFS client.
- So, even if a file is opened and locked by an NFS client, Samba let a 
smb client access the file ? Is there a parameter to change this behaviour 
?

- On the other hand, could you confirm me that, in case of a file opened 
and locked by an smb client, Samba server locks the file, then NFS client 
could check the lock ?

- Could you please explain me what "hack for NFS" means in open.c ?

- Do I miss something ?

open.c :

 /*note that we ignore failure for the following. It is
           basically a hack for NFS, and NFS will never set one of
           these only read them. Nobody but Samba can ever set a deny
           mode and we have already checked our more authoritative
           locking database for permission to set this deny mode. If
           the kernel refuses the operations then the kernel is wrong  */

        kernel_flock(fsp, share_access);

        /*
         * At this point onwards, we can guarentee that the share entry
         * is locked, whether we created the file or not, and that the
         * deny mode is compatible with all current opens.
         */

kernel_flock :
/****************************************************************************
 Set a kernel flock on a file for NFS interoperability.
 This requires a patch to Linux.
****************************************************************************/

static void kernel_flock(files_struct *fsp, uint32 share_mode)
{
#if HAVE_KERNEL_SHARE_MODES
        int kernel_mode = 0;
        if (share_mode == FILE_SHARE_WRITE) {
                kernel_mode = LOCK_MAND|LOCK_WRITE;
        } else if (share_mode == FILE_SHARE_READ) {
                kernel_mode = LOCK_MAND|LOCK_READ;
        } else if (share_mode == FILE_SHARE_NONE) {
                kernel_mode = LOCK_MAND;
        }
        if (kernel_mode) {
                flock(fsp->fh->fd, kernel_mode);
        }
#endif
        ;
}

Regards,

No ideas about this subject ?
>>>
Hi there,

We are thinking about sharing same files:
- OS2/Win clients with Samba
- Linux clients with NFS.
So, the same files would be shared by 2 different protocols.

Looking at the open.c samba code, there seems to be no check / no error 
(sharing violation) returned to the smb client when the file is already 
locked by an NFS client.
- So, even if a file is opened and locked by an NFS client, Samba let a 
smb client access the file ? Is there a parameter to change this behaviour 
?

- On the other hand, could you confirm me that, in case of a file opened 
and locked by an smb client, Samba server locks the file, then NFS client 
could check the lock ?

- Could you please explain me what "hack for NFS" means in open.c ?

- Do I miss something ?

open.c :

 /*note that we ignore failure for the following. It is
           basically a hack for NFS, and NFS will never set one of
           these only read them. Nobody but Samba can ever set a deny
           mode and we have already checked our more authoritative
           locking database for permission to set this deny mode. If
           the kernel refuses the operations then the kernel is wrong  */

        kernel_flock(fsp, share_access);

        /*
         * At this point onwards, we can guarentee that the share entry
         * is locked, whether we created the file or not, and that the
         * deny mode is compatible with all current opens.
         */

kernel_flock :
/****************************************************************************
 Set a kernel flock on a file for NFS interoperability.
 This requires a patch to Linux.
****************************************************************************/

static void kernel_flock(files_struct *fsp, uint32 share_mode)
{
#if HAVE_KERNEL_SHARE_MODES
        int kernel_mode = 0;
        if (share_mode == FILE_SHARE_WRITE) {
                kernel_mode = LOCK_MAND|LOCK_WRITE;
        } else if (share_mode == FILE_SHARE_READ) {
                kernel_mode = LOCK_MAND|LOCK_READ;
        } else if (share_mode == FILE_SHARE_NONE) {
                kernel_mode = LOCK_MAND;
        }
        if (kernel_mode) {
                flock(fsp->fh->fd, kernel_mode);
        }
#endif
        ;
}

Regards,

So basic question : is NFS application able to use deny modes ?
If not, how samba could check deny mode opening a file already opened by 
an NFS client ?
Could byte range lock be a way to "share" deny modes between NFS and
Samba
? 
DENY_WRITE would be F_RDLCK ?
DENY_READ would be F_WRLCK ?

My samba clients are OS2 clients. It would be difficult to modify the 
application side. New clients are Linux/NFS : it would be easier to adapt 
the NFS linux code to correctly manage share modes between samaba & NFS.

On Sun, Mar 18, 2007 at 07:13:34PM +0100, Alain.Gorlier@altissemiconductor.com
wrote:
> So basic question : is NFS application able to use deny modes ?
No. Posix just does not have that concept.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.samba.org/archive/samba/attachments/20070318/7308c119/attachment.bin

On Sun, Mar 18, 2007 at 07:13:34PM +0100, Alain.Gorlier@altissemiconductor.com
wrote:
> My samba clients are OS2 clients. It would be difficult to modify the 
> application side. New clients are Linux/NFS : it would be easier to adapt 
> the NFS linux code to correctly manage share modes between samaba &
NFS.
Quick question: What cross-platform applications are we
talking about? It must be apps that access files
concurrently from OS/2 and Linux/NFS and get locking right.
What is it? The only one that I know of that would do it
would be OpenOffice, and this used to have issues with
cross-platform locking.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.samba.org/archive/samba/attachments/20070318/7d90be9c/attachment.bin

>> Quick question: What cross-platform applications are we
>> talking about? It must be apps that access files
>> concurrently from OS/2 and Linux/NFS and get locking right.
>> What is it? The only one that I know of that would do it
>> would be OpenOffice, and this used to have issues with
>> cross-platform locking.
We are talking about internal manufacturing application. 
1000 OS2 clients ! a great number of them would be migrated as Linux NFS 
clients.
The OS2 clients are using the 'sopen' function with deny modes.

>> Alain, I'm trying to integrate into an OS/2 environment - without
much
luck. 
>> Basically I have a server running the last available OS/2 Warp 4 based 
version
>> usually referred to as ACP2 with multiple Warp 4 clients.  Any quick 
tips on
>> getting Samba to play nice on an OS/2 Domain?
Hi Will,
What kind of problems do you encountered ?
We are at the same OS2 level.

We're only in test phase for manufacturing applications. 
No big problems encountered with OS2 support applications except 
performance problem with huge directories resolved with "uppercase" 
parameters.

OS2 are still logged on OS2 domain, Samba authentication is done with 
LDAP.
When all of the OS2 clients would be migrated to Linux, OS2 domain 
controller would be stopped.

>> And what API do you have in mind to use on the Linux side?
Perhaps we could use byte range locks at NFS client side 
and modify Samba server side to check byte range locks opening the file :
- if no lock : apply byte range locks and open the file
- if there is a lock : return to the smb client a sharing violation

>> I'm just starting but as of now, none of the Linux boxes see the
OS/2
domain
>> controller or any of the OS/2 peers other than the one I have eCS on - 
that one
>> has a patched version of the file and print client which is still 
problematic -
>> it is supposed to be compatible with SAMBA 3.0.2 but they goofed on a 
few of
>> the WPS class iinterfaces.  I guess you would say I'm stuck at the 
starting
>> line.
Our OS2 clients are still logging to OS2 domain controllers.
Our Linux clients are NFS clients.
>> I have the OS/2 server configured with TCPBEUI using B-Node with no 
defined
>> NETBIOS nameserver or other parameters beyond the defaults.  I
haven't
dealt
>> with TCPBEUI for several years, so likely I'm missing a simple
setting
>> somewhere.  Between that and fighting the !@#$#$%^ firewall on the box 
I intend
>> for the domain controller (SUSE 10.2) is enough to make me glad this 
isn't a
>> full time job anymore.  Any unusual settings or tricks you may have 
used would
>> be appreciated.
Our OS2 clients are H-NODE (using WINS servers). With B-Node be sure you 
can join fileservers using broadcasts (or OS2 rfcbcst.lst or rfcnames.lst 
files)
Our OS2 servers are also H-NODE.
OS2 domain controllers are also H-NODE. They are describes in the 
rfcbcst.lst file of the OS2 clients (our OS2 DC and servers are in 
different subnets that OS2 clients).
Our future Linux samba servers are also described in the WINS servers.

Could you please open a new subject ? (We are no more talking about 
NFS/Samba locks...), 
Thanks ;-)

>> Nope. Won't happen. Share modes are share modes and byte
>> range locks are byte range locks. We will not add code that
>> mixes those two. This is really something the app must take
>> care of.
I understand your point of view.
But, we do/can NOT want to modify our OS2 applications.
So, we have to keep OS2 deny mode method and migrate OS2 SMB clients 1 by 
1 to Linux NFS client with no loss of file integrity...
Then, we are thinking about modifying Samba server code to "emulate"
deny
modes with byte range locks....

Any idea about another way to resolve this point ?

On Thu, Mar 22, 2007 at 06:35:22PM +0100, Alain.Gorlier@altissemiconductor.com
wrote:
> Any idea about another way to resolve this point ?
You might want to talk to the Linux kernel guys about adding
Windows-style share modes. If the Linux kernel added those
with exact Windows semantics, it would be trivial to pass
them through cifsfs.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.samba.org/archive/samba/attachments/20070322/d9aa1b97/attachment.bin