samba - Feb 2007 - Samba-3.0.23c kernel lock problems with new Redhat kernel 2.6.9-42.0.8

We run samba-3.0.23c on some Redhat RHEL4 servers, and Samba used to work
like a charm.  But then a couple of days ago we upgraded the kernel
on the Samba servers to kernel-smp-2.6.9-42.0.8.EL.  All of a sudden
our Windows users could not use Microsoft Office with files on the
Samba shares :-(

Our filesystems are actually NFS-mounted by the Samba server from
another server, and the Samba server showed these log entries:

Feb  1 13:27:41 serv309 smbd[11728]: [2007/02/01 13:27:41, 0] 
locking/posix.c:posix_fcntl_lock(660)
Feb  1 13:27:41 serv309 smbd[11728]:   posix_fcntl_lock: WARNING: lock request 
at offset 2147483538, length 1 returned
Feb  1 13:27:41 serv309 smbd[11728]: [2007/02/01 13:27:41, 0] 
locking/posix.c:posix_fcntl_lock(661)
Feb  1 13:27:41 serv309 smbd[11728]:   an No locks available error. This can 
happen when using 64 bit lock offsets
Feb  1 13:27:41 serv309 smbd[11728]: [2007/02/01 13:27:41, 0] 
locking/posix.c:posix_fcntl_lock(662)
Feb  1 13:27:41 serv309 smbd[11728]:   on 32 bit NFS mounted file systems.
Feb  1 13:27:41 serv309 smbd[11728]: [2007/02/01 13:27:41, 0] 
locking/posix.c:posix_fcntl_lock(660)
Feb  1 13:27:41 serv309 kernel: lockd: cannot monitor 130.225.87.40
Feb  1 13:27:41 serv309 kernel: lockd: failed to monitor 130.225.87.40

With the previous kernel kernel-smp-2.6.9-42.0.3.EL there were no
such problems !  The Redhat kernel Release Notes
    https://rhn.redhat.com/errata/RHSA-2007-0014.html
do not mention any changes that seem to be related to Samba or NFS or locking.

Fortunately I found this article
    http://lists.samba.org/archive/samba/2006-October/126638.html
where Jeremy recommends to use "posix locking = no", and indeed
this fixes the problem !

Hopefully these observations can help others, but a real solution
to the problem would be most welcome !

-- 
Ole Holm Nielsen
Department of Physics, Technical University of Denmark

Olm,

What are the details (OS/type, etc.) of the NFS server that you are 
mounting these resources from?   Is it possible that you are mounting 
an older 32 bit NFS service from a system that is evidently 64 bit capable?

-D

At 09:45 AM 2/2/2007, Ole Holm Nielsen wrote:
>We run samba-3.0.23c on some Redhat RHEL4 servers, and Samba used to work
>like a charm.  But then a couple of days ago we upgraded the kernel
>on the Samba servers to kernel-smp-2.6.9-42.0.8.EL.  All of a sudden
>our Windows users could not use Microsoft Office with files on the
>Samba shares :-(
>
>Our filesystems are actually NFS-mounted by the Samba server from
>another server, and the Samba server showed these log entries:
>
>...
>
>With the previous kernel kernel-smp-2.6.9-42.0.3.EL there were no
>such problems !  The Redhat kernel Release Notes
>    https://rhn.redhat.com/errata/RHSA-2007-0014.html
>do not mention any changes that seem to be related to Samba or NFS or
locking.
>
>Fortunately I found this article
>    http://lists.samba.org/archive/samba/2006-October/126638.html
>where Jeremy recommends to use "posix locking = no", and indeed
>this fixes the problem !
>
>Hopefully these observations can help others, but a real solution
>to the problem would be most welcome !
>
>--
>Ole Holm Nielsen
>Department of Physics, Technical University of Denmark
Don Meyer                                           <dlmeyer@uiuc.edu>
Network Manager, ACES Academic Computing Facility
Technical System Manager, ACES TeleNet System
UIUC College of ACES, Information Technology and Communication Services

   "They that can give up essential liberty to obtain a little 
temporary safety,
         deserve neither liberty or safety."     -- Benjamin Franklin, 1759

On Fri, Feb 02, 2007 at 04:45:08PM +0100, Ole Holm Nielsen
wrote:
> We run samba-3.0.23c on some Redhat RHEL4 servers, and Samba used to work
> like a charm.  But then a couple of days ago we upgraded the kernel
> on the Samba servers to kernel-smp-2.6.9-42.0.8.EL.  All of a sudden
> our Windows users could not use Microsoft Office with files on the
> Samba shares :-(
> 
> Our filesystems are actually NFS-mounted by the Samba server from
> another server, and the Samba server showed these log entries:
> 
> Feb  1 13:27:41 serv309 smbd[11728]: [2007/02/01 13:27:41, 0] 
> locking/posix.c:posix_fcntl_lock(660)
> Feb  1 13:27:41 serv309 smbd[11728]:   posix_fcntl_lock: WARNING: lock 
> request at offset 2147483538, length 1 returned
> Feb  1 13:27:41 serv309 smbd[11728]: [2007/02/01 13:27:41, 0] 
> locking/posix.c:posix_fcntl_lock(661)
> Feb  1 13:27:41 serv309 smbd[11728]:   an No locks available error. This 
> can happen when using 64 bit lock offsets
> Feb  1 13:27:41 serv309 smbd[11728]: [2007/02/01 13:27:41, 0] 
> locking/posix.c:posix_fcntl_lock(662)
> Feb  1 13:27:41 serv309 smbd[11728]:   on 32 bit NFS mounted file systems.
> Feb  1 13:27:41 serv309 smbd[11728]: [2007/02/01 13:27:41, 0] 
> locking/posix.c:posix_fcntl_lock(660)
> Feb  1 13:27:41 serv309 kernel: lockd: cannot monitor 130.225.87.40
> Feb  1 13:27:41 serv309 kernel: lockd: failed to monitor 130.225.87.40
> 
> With the previous kernel kernel-smp-2.6.9-42.0.3.EL there were no
> such problems !  The Redhat kernel Release Notes
>    https://rhn.redhat.com/errata/RHSA-2007-0014.html
> do not mention any changes that seem to be related to Samba or NFS or 
> locking.
> 
> Fortunately I found this article
>    http://lists.samba.org/archive/samba/2006-October/126638.html
> where Jeremy recommends to use "posix locking = no", and indeed
> this fixes the problem !
> 
> Hopefully these observations can help others, but a real solution
> to the problem would be most welcome !
Looks like a kernel issue to me. Have you reported this to Red Hat ?

Jeremy.

Hi Don,
> What are the details (OS/type, etc.) of the NFS server that you are 
> mounting these resources from?   Is it possible that you are mounting an 
> older 32 bit NFS service from a system that is evidently 64 bit capable?
Samba server: RHEL4 (32-bit Intel Xeon 2.4 GHz).
NFS server: RHEL3 (32-bit Intel Xeon 2.8 GHz).
The RHEL servers are fully patched.
Please note that the problem was introduced by a kernel upgrade
on the Samba RHEL4 server.

Thanks,
Ole

-- 
Ole Holm Nielsen
Department of Physics, Technical University of Denmark

On 2/2/07, Ole Holm Nielsen <Ole.H.Nielsen@fysik.dtu.dk>
wrote:
> We run samba-3.0.23c on some Redhat RHEL4 servers, and Samba used to work
> like a charm.  But then a couple of days ago we upgraded the kernel
> on the Samba servers to kernel-smp-2.6.9-42.0.8.EL.  All of a sudden
> our Windows users could not use Microsoft Office with files on the
> Samba shares :-(
>
Was it complaining that they are read only or that after saving a file
that existed it word claimed that it could not save the file? I am
asking as after I upgraded from samba-3.0.22 to samba-3.0.23 on gentoo
I had these symptoms and the fix was very easy.

John

John Drescher wrote:
> On 2/2/07, Ole Holm Nielsen <Ole.H.Nielsen at fysik.dtu.dk> wrote:
> > We run samba-3.0.23c on some Redhat RHEL4 servers, and Samba used to
work
> > like a charm.  But then a couple of days ago we upgraded the kernel
> > on the Samba servers to kernel-smp-2.6.9-42.0.8.EL.  All of a sudden
> > our Windows users could not use Microsoft Office with files on the
> > Samba shares :-(
> >
> Was it complaining that they are read only or that after saving a file
> that existed it word claimed that it could not save the file? I am
> asking as after I upgraded from samba-3.0.22 to samba-3.0.23 on gentoo
> I had these symptoms and the fix was very easy.
Do you have a hint / link for the fix?

Rupert

> > Was it complaining that they are read only or that after saving a file
> > that existed it word claimed that it could not save the file? I am
> > asking as after I upgraded from samba-3.0.22 to samba-3.0.23 on gentoo
> > I had these symptoms and the fix was very easy.
>
> Do you have a hint / link for the fix?
>
It  was an old problem at least on the samba list although for some
reason we have not seen it until the upgrade. The problem is office
when it saves a file it deletes the current file saves a new temp file
than renames the temp file to the old file name. In this case windows
assigns the same permissions for a file in the same folder with the
same name of one that was recently deleted. The problem here is linux
has no such built in magic so the operation fails.

Here is a bit of my smb.conf file with the fixes. The key is the masks:

[Profiles]
    path = /home/%U/%U.pds
    browseable = no
    guest ok = yes

# A publicly accessible directory, but read only, except for people in
# the "staff" group
[Public]
   comment = Public Stuff
   path = /mnt/vg/public
   public = yes
   writable = yes
   create mask = 777
   directory mask = 777

   inherit acls = yes
   inherit permissions = yes

[Users]
   comment = User Directories
   path = /home
   writable = yes
   create mask = 777
   directory mask = 777
   inherit acls = yes
   inherit permissions = yes
[Images]
  comment = Scrubbed Images
  path = /mnt/vg/image-root
  read only = no
  writable = yes
  public = yes

John