samba - Mar 2005 - [SMB 3.0.10] File Locking Mechanism Windows <-> Unix

Hello,

Iam facing a problem in locking of files across samba shares. We have samba
3.0.10 running on Solaris 9 with the smb.conf as follows.

# Global parameters
[global]
       workgroup = NMUINT
        netbios name = NMUINTFS
        interfaces = <IP>
        bind interfaces only = Yes
        security = DOMAIN
        password server = XXX.XXX.XXX.XXX
        log level = 1
        ldap ssl = no
        #oplocks = no
        kernel oplocks = no

[Share1]
        path = /export/home/Testdev/share
        read only = No
        oplocks = no
        strict locking = yes
        level2 oplocks = no


The files under this directory are modified both from Windows and Solaris
programatically. When ever a process accesses a file in this directory, it
opens it in an exclusive mode ( DENY_ALL ). Now, this works fine between two
processes on Windows and between two UNIX process (Gives equivalent of
Winods error  53, File is used by another process) . But this does not work
between Winodws and Unix. i.e Both of them are able to open the file in
exclusive mode!! I ran the 'fuser' command in such a situation ( when
both
had exclusive accesses to the file) and to my surprise I found that both
smbd and the unix process are listed

bash-2.05# fuser /export/home/Testdev/share/test.txt
/export/home/Testdev/share/test.txt:     1655o    1567o 

bash-2.05# ps -e | grep filetest
    1655 pts/5    0:00 filetest
bash-2.05# ps -e | grep 1567
1567 ?        0:00 smbd

Also I tried to rename the file when only samba was locking it . The rename
was successful. This is not possible if only unix process (filetest) is
locking it. It will fail with a Permission denied error.

Can any one help me in getting this file lock working? 
Thanking you in anticipation
asif

On Mon, Mar 14, 2005 at 03:12:34PM +0530, Asif, M wrote:
> 
> The files under this directory are modified both from Windows and Solaris
> programatically. When ever a process accesses a file in this directory, it
> opens it in an exclusive mode ( DENY_ALL ). Now, this works fine between
two
> processes on Windows and between two UNIX process (Gives equivalent of
> Winods error  53, File is used by another process) . But this does not work
> between Winodws and Unix. i.e Both of them are able to open the file in
> exclusive mode!! I ran the 'fuser' command in such a situation (
when both
> had exclusive accesses to the file) and to my surprise I found that both
> smbd and the unix process are listed
What is the UNIX process doing to enforce exclusivity ? What system call
do you think it does ?

Remember, share modes have no meaning on UNIX.

Jeremy.

Hello Jeremy,

Thanks for your response.

I tried the following

On Windows side, an MFC application with the code given below access the
file using the samba share.


			CString strFile _T("\\\\180.144.1.11\\netmbase\\tmp\\test.txt");
		CStdioFile fValueFile;
			if (!fValueFile.Open( strFile ,CFile::modeWrite |
CFile::shareExclusive    ) )
			{
				wcout<<_T("Open failed")<<endl;
			}
			else
			{
				//wcout<<_T("Open Success")<<endl;
			}

		fValueFile.WriteString( strt );
		getchar()

		fValueFile.Close();

On UNIX side, code is something similar to this

		int fid open("/export/home/scsd13/kiran/NetMBase/tmp/test.txt",
O_RDWR|O_EXCL ) ;
		if( 0 > fid )
		{
			perror("open"),exit(1);
		}

		struct flock lockDetails ;
		lockDetails.l_start = 0 ;
		lockDetails.l_whence = SEEK_SET;
		lockDetails.l_len = 0 ;
		lockDetails.l_type = F_WRLCK ;
		int nErr = fcntl( fid, F_SETLK, &lockDetails);
		if( 0 > nErr )
		{
			perror("lock"),exit(1);
		}
		getchar();
		close(fid);
	
Now,

1. Two instances of the executable runs on Windows side, open fails with
sharing violation if the first one is not released ( blocked at getchar()
call) , no problem.
2. Same is the case with two instances of UNIX processes.
3.The unix process locks the file and does not release it (blocked at
getchar() ), and then the windows client is executed, WriteString throws an
exceptoin giving error 33(locked by other process). No problem 4. Now if the
Windows client opens the file first (blocked at getchar() ) and then the
unix client is invoked, the fcntl call succeeds... 

I tried lockf() instead of fcntl(), turned on mandatory locking etc, but
with no success.

Am I missing out some thing? Is there an easier way for getting this work?
Basically, I want to ensure that there is no read happening when any one
(from unix or windows) is writing into the file an vice versa.

Thanks a lot for your patience
Asif

-----Original Message-----
From: Jeremy Allison [mailto:jra@samba.org]
Sent: Tuesday, March 15, 2005 12:37 AM
To: Asif, M
Cc: samba@lists.samba.org
Subject: Re: [Samba] [SMB 3.0.10] File Locking Mechanism Windows <-> Unix

On Mon, Mar 14, 2005 at 03:12:34PM +0530, Asif, M wrote:
> 
> The files under this directory are modified both from Windows and 
> Solaris programatically. When ever a process accesses a file in this 
> directory, it opens it in an exclusive mode ( DENY_ALL ). Now, this 
> works fine between two processes on Windows and between two UNIX 
> process (Gives equivalent of Winods error  53, File is used by another
> process) . But this does not work between Winodws and Unix. i.e Both 
> of them are able to open the file in exclusive mode!! I ran the 
> 'fuser' command in such a situation ( when both had exclusive
accesses
> to the file) and to my surprise I found that both smbd and the unix 
> process are listed
What is the UNIX process doing to enforce exclusivity ? What system call do
you think it does ?

Remember, share modes have no meaning on UNIX.

Jeremy.

On Tue, Mar 15, 2005 at 07:54:38PM +0530, Asif, M wrote:
> Hello Jeremy,
> 
> Thanks for your response.
> 
> I tried the following
> 
> On Windows side, an MFC application with the code given below access the
> file using the samba share.
> 
> 
> 			CString strFile >
_T("\\\\180.144.1.11\\netmbase\\tmp\\test.txt");
> 		CStdioFile fValueFile;
> 			if (!fValueFile.Open( strFile ,CFile::modeWrite |
> CFile::shareExclusive    ) )
> 			{
> 				wcout<<_T("Open failed")<<endl;
> 			}
> 			else
> 			{
> 				//wcout<<_T("Open Success")<<endl;
> 			}
> 
> 		fValueFile.WriteString( strt );
> 		getchar()
> 
> 		fValueFile.Close();
> 
> On UNIX side, code is something similar to this
> 
> 		int fid >
open("/export/home/scsd13/kiran/NetMBase/tmp/test.txt", O_RDWR|O_EXCL
) ;
> 		if( 0 > fid )
> 		{
> 			perror("open"),exit(1);
> 		}
> 
> 		struct flock lockDetails ;
> 		lockDetails.l_start = 0 ;
> 		lockDetails.l_whence = SEEK_SET;
> 		lockDetails.l_len = 0 ;
> 		lockDetails.l_type = F_WRLCK ;
> 		int nErr = fcntl( fid, F_SETLK, &lockDetails);
> 		if( 0 > nErr )
> 		{
> 			perror("lock"),exit(1);
> 		}
> 		getchar();
> 		close(fid);
> 	
> Now,
> 
> 1. Two instances of the executable runs on Windows side, open fails with
> sharing violation if the first one is not released ( blocked at getchar()
> call) , no problem.
> 2. Same is the case with two instances of UNIX processes.
> 3.The unix process locks the file and does not release it (blocked at
> getchar() ), and then the windows client is executed, WriteString throws an
> exceptoin giving error 33(locked by other process). No problem 4. Now if
the
> Windows client opens the file first (blocked at getchar() ) and then the
> unix client is invoked, the fcntl call succeeds... 
> 
> I tried lockf() instead of fcntl(), turned on mandatory locking etc, but
> with no success.
> 
> Am I missing out some thing? Is there an easier way for getting this work?
> Basically, I want to ensure that there is no read happening when any one
> (from unix or windows) is writing into the file an vice versa.
What OS are you running on ? This code will work on Linux with kernel
oplocks, and if you turn off oplocks should work on other UNIXes.

Jeremy.

Hello Jeremy,

We have samba 3.0.10 running on Solaris 9 with the smb.conf as follows.
<http://lists.samba.org/archive/samba/2005-March/101953.html>

# Global parameters
[global]
workgroup = NMUINT
netbios name = NMUINTFS
interfaces = <IP>
bind interfaces only = Yes
security = DOMAIN
password server = XXX.XXX.XXX.XXX
log level = 1
ldap ssl = no
#oplocks = no
kernel oplocks = no

[Share1]
path = /export/home/Testdev/share
read only = No
oplocks = no
strict locking = yes
level2 oplocks = no

Oplocks were disabled. Any idea what else could be the problem?

Thanks and best regards,
Asif

-----Original Message-----
From: Jeremy Allison [mailto:jra@samba.org] 
Sent: Tuesday, March 15, 2005 11:33 PM
To: Asif, M
Cc: samba@samba.org
Subject: Re: [Samba] [SMB 3.0.10] File Locking Mechanism Windows <-> Unix

On Tue, Mar 15, 2005 at 07:54:38PM +0530, Asif, M wrote:
> Hello Jeremy,
> 
> Thanks for your response.
> 
> I tried the following
> 
> On Windows side, an MFC application with the code given below access 
> the file using the samba share.
> 
> 
> 			CString strFile >
_T("\\\\180.144.1.11\\netmbase\\tmp\\test.txt");
> 		CStdioFile fValueFile;
> 			if (!fValueFile.Open( strFile ,CFile::modeWrite |
> CFile::shareExclusive    ) )
> 			{
> 				wcout<<_T("Open failed")<<endl;
> 			}
> 			else
> 			{
> 				//wcout<<_T("Open Success")<<endl;
> 			}
> 
> 		fValueFile.WriteString( strt );
> 		getchar()
> 
> 		fValueFile.Close();
> 
> On UNIX side, code is something similar to this
> 
> 		int fid >
open("/export/home/scsd13/kiran/NetMBase/tmp/test.txt", O_RDWR|O_EXCL
) ;
> 		if( 0 > fid )
> 		{
> 			perror("open"),exit(1);
> 		}
> 
> 		struct flock lockDetails ;
> 		lockDetails.l_start = 0 ;
> 		lockDetails.l_whence = SEEK_SET;
> 		lockDetails.l_len = 0 ;
> 		lockDetails.l_type = F_WRLCK ;
> 		int nErr = fcntl( fid, F_SETLK, &lockDetails);
> 		if( 0 > nErr )
> 		{
> 			perror("lock"),exit(1);
> 		}
> 		getchar();
> 		close(fid);
> 	
> Now,
> 
> 1. Two instances of the executable runs on Windows side, open fails 
> with sharing violation if the first one is not released ( blocked at 
> getchar()
> call) , no problem.
> 2. Same is the case with two instances of UNIX processes.
> 3.The unix process locks the file and does not release it (blocked at
> getchar() ), and then the windows client is executed, WriteString 
> throws an exceptoin giving error 33(locked by other process). No 
> problem 4. Now if the Windows client opens the file first (blocked at 
> getchar() ) and then the unix client is invoked, the fcntl call
succeeds...
> 
> I tried lockf() instead of fcntl(), turned on mandatory locking etc, 
> but with no success.
> 
> Am I missing out some thing? Is there an easier way for getting this work?
> Basically, I want to ensure that there is no read happening when any 
> one (from unix or windows) is writing into the file an vice versa.
What OS are you running on ? This code will work on Linux with kernel
oplocks, and if you turn off oplocks should work on other UNIXes.

Jeremy.