Good day, Our Windows users aren't able to edit their MS Office files over our Samba shares (Samba 3.0.10, CentOS4 w/ their i386 RPM). It looks like the clients' attempts to lock the files fails. When their client attempts to open such a file, Samba reports: ----------8<----------------------- [2006/10/27 15:55:57, 0] locking/posix.c:posix_fcntl_lock(657) posix_fcntl_lock: WARNING: lock request at offset 2147483538, length 1 returned [2006/10/27 15:55:57, 0] locking/posix.c:posix_fcntl_lock(658) an No locks available error. This can happen when using 64 bit lock offsets [2006/10/27 15:55:57, 0] locking/posix.c:posix_fcntl_lock(659) on 32 bit NFS mounted file systems. ----------8<----------------------- The filesystem the file is on is indeed a NFS filesystem mounted from a Netapp device, although I have no idea if Samba tried a 64-bit lock. The machine and Samba binary are 32-bit, although I am guessing Samba thinks it's supposed to use 64-bit locks. But, I have no idea how to actually fix this problem. I've found lots of posts with people with this issue, and a couple others describing the details of the problem and why it happens, but none actually resolving it- other than one suggestion to set "locking no", which is obviously not desirable at all! Can someone suggest how this could be resolved? Thanks! ===========================Darren Gamble Systems Architect, Regional Services Shaw Cablesystems GP 630 - 3rd Avenue SW Calgary, Alberta, Canada T2P 4L4 (403) 781-4948 ?
On Mon, Oct 30, 2006 at 11:03:45AM -0700, Darren Gamble wrote:> Good day, > > Our Windows users aren't able to edit their MS Office files over our Samba shares (Samba 3.0.10, CentOS4 w/ their i386 RPM). It looks like the clients' attempts to lock the files fails. When their client attempts to open such a file, Samba reports: > > ----------8<----------------------- > [2006/10/27 15:55:57, 0] locking/posix.c:posix_fcntl_lock(657) > posix_fcntl_lock: WARNING: lock request at offset 2147483538, length 1 returned > [2006/10/27 15:55:57, 0] locking/posix.c:posix_fcntl_lock(658) > an No locks available error. This can happen when using 64 bit lock offsets > [2006/10/27 15:55:57, 0] locking/posix.c:posix_fcntl_lock(659) > on 32 bit NFS mounted file systems. > ----------8<----------------------- > > > The filesystem the file is on is indeed a NFS filesystem mounted from a Netapp device, although I have no idea if Samba tried a 64-bit lock. The machine and Samba binary are 32-bit, although I am guessing Samba thinks it's supposed to use 64-bit locks. > > But, I have no idea how to actually fix this problem. I've found lots of posts with people with this issue, and a couple others describing the details of the problem and why it happens, but none actually resolving it- other than one suggestion to set "locking no", which is obviously not desirable at all! > > Can someone suggest how this could be resolved? Thanks!You can set the parameter "posix locking = no" which prevents Samba from mapping the 64-bit Windows locks onto the underlying NFS filesystem. Windows clients to the same Samba server will still see the Windows locks, they're preserved inside Samba. The only difference is local UNIX processes won't see the Windows locks - but I doubt that you have anyone editing the Word files simultaneously anywy. This is a bug in the NetApp NFS locking, not in Samba. Jeremy.
Good day, Thanks for your reply!> You can set the parameter "posix locking = no" which prevents > Samba from mapping the 64-bit Windows locks onto the underlying > NFS filesystem. Windows clients to the same Samba server will > still see the Windows locks, they're preserved inside Samba. > The only difference is local UNIX processes won't see the > Windows locks - but I doubt that you have anyone editing > the Word files simultaneously anywy.OK, I'll try this out, thanks! This looks like it should be safe to do in our setup.> This is a bug in the NetApp NFS locking, not in Samba.If Samba is trying to issue a 64-bit lock, that obviously is not going to work since NFS is 32-bit. I'm not sure how this could be a NFS issue, unless you're expecting the server to re-map it as 32-bit. Maybe I'm missing something here? Here is more information on the topic. This user suggested to hack the configure script to force 32-bit locks to get around this. Perhaps the right solution is to detect the right lock size, or retry with 32-bit if 64-bit fails? http://lists.samba.org/archive/samba/2004-January/079217.html ===========================Darren Gamble Systems Architect, Regional Services Shaw Cablesystems GP 630 - 3rd Avenue SW Calgary, Alberta, Canada T2P 4L4 (403) 781-4948