[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