[Samba] Samba locking with NFS backend.

Jan Hugo Prins jhp at jhprins.org
Mon Jan 7 21:38:30 GMT 2008


I'm in a bit of a loss at the moment.
We have the following situation, we are running Samba for a lot of small 
companies that need fileservices for there Windows Terminal Servers that 
they use through a thin client on a Fiber / Lan extention to our datacentre.
We have this samba running on 2 linux hosts (Fedora Core 5 and Fedora 7) 
with a ldap backend for all the domains.
This works ok, except for 1 thing.
In the past we synced server1 to server2 every hour and when there was a 
problems with a server, the users would only loose 1 hour of work at 
most and server 2 would take over all configurations. So far so good, 
when there are not too much customers.
But we have had some growth recently and we added a central NFS server 
to our setup. This server (Isilon IQ9000) is fully redundant so in 
theory we could put any number of Samba frontend servers in front of it, 
and we don't have to sync anymore.
But now the problem, when we put the user data on the NFS backend, users 
are complaining that they are not able to edit documents in Word because 
they get a error that they can only open the file readonly. Excell the 
same problem. But copying a file for example works ok. In general you 
can divide the applications in 2 groups, 1 only readonly access to the 
data, and 1 no problem.
I found the following link that describes my problem rather well, but 
I'm not able to test this sollution because it involved some patch 
reverting etc to old kernels.
http://blog.notreally.org/ (blog entry of dec, 19th 2007). I could do 
the memory hack that is described there to test if this is actually my 
problem, but I thought, let's first ask here.

The following lines from the blog seem to describe my problem really 
well, don't know if it really is my problem though, because I really 
don't know how to check this appart from memory hacking:

"Unfortunately, linux 2.6.12 adds flock() emulation to the Linux NFS 
client by translating it into a file-wide fcntl(). This means that 
flock()s and fcntl()s *do collide* on remote NFS shares, which 
introduces all the potential application race conditions which Linux 
avoided by having them oblivious to each other locally. The practical 
upshot of this is that if you re-share an NFS share via samba, then if a 
Windows client (e.g. Outlook opening a PST file) opens a file with a 
share mode, then byte-range locking operations will fail as the lock has 
already been acquired. (The fact that NFS doesn’t realise the same PID 
has both locks and allow them both is probably an even bigger problem)."

Is this a known issue with a sollution, or have I fould a problem here 
without a current sollution?

Thanks a lot,
Jan Hugo Prins

More information about the samba mailing list