[Samba] Request for explanation on NFS re-export issue

Ray Van Dolson rvandolson at esri.com
Mon Aug 6 22:03:09 GMT 2007

I have a situation involving Samba that I _believe_ may be the fault of
a buggy or old NFS daemon, but am not sure.  I'm hoping someone can
explain to me what is going on here (I have found a workaround).

I have a Samba server on Fedora 7 (3.0.25b + whatever patches Fedora
includes).  This server exports a share called software which points to
a local directory on that server /software.

Within /software there are two symbolic links, one pointing to:


And the other to:


Both of these are managed via the automounter and are being exported by
NFS on machine1 and machine 2 respectively.  machine1 is a RHEL4 system
while machine2 is a very old HP-UX machine.

When a CIFS client accesses my Samba server and enters the directory
pointed to by the machine1 symlink, it can retrieve all files
flawlessly.  However, when doing the same with files under the symlink
to machine2, access to all files "hangs" and eventually times out.

Access to NFS-exported files on the HP-UX machine is fine when logged
into the Samba server machine locally and using NFS-only.

When the CIFS client is attempting to access the HP-UX-based files, I
see the following in my messages file:

Aug  3 15:14:49 leoray kernel: rpcbind: server xavier not responding, timed out
Aug  3 15:14:49 leoray kernel: lockd: couldn't create RPC handle for xavier
Aug  3 15:14:49 leoray smbd[5259]: [2007/08/03 15:14:49, 0] locking/posix.c:posix_fcntl_getlock(242) 
Aug  3 15:14:49 leoray smbd[5259]:   posix_fcntl_getlock: WARNING: lock request at offset 0, length 16384 returned 
Aug  3 15:14:49 leoray smbd[5259]: [2007/08/03 15:14:49, 0] locking/posix.c:posix_fcntl_getlock(243) 
Aug  3 15:14:49 leoray smbd[5259]:   an No locks available error. This can happen when using 64 bit lock offsets 
Aug  3 15:14:49 leoray smbd[5259]: [2007/08/03 15:14:49, 0] locking/posix.c:posix_fcntl_getlock(244) 
Aug  3 15:14:49 leoray smbd[5259]:   on 32 bit NFS mounted file systems. 
Aug  3 15:14:49 leoray smbd[5259]: [2007/08/03 15:14:49, 0] lib/util_sock.c:write_data(562) 
Aug  3 15:14:49 leoray smbd[5259]:   write_data: write failure in writing to client Error Broken pipe 
Aug  3 15:14:49 leoray smbd[5259]: [2007/08/03 15:14:49, 0] lib/util_sock.c:send_smb(769) 
Aug  3 15:14:49 leoray smbd[5259]:   Error writing 16447 bytes to client. -1. (Broken pipe) 

A tcpdump shows the Samba server talking to the RPC lock daemon on the
HP-UX machine (communication going back and forth), but it just appears
the same message is sent back and forth over and over again until
finally the transfer times out.

I'm inclined to blame some incompatability with the NFS daemon running
on the HP-UX machine.  I have seen a few other mailing lists posts,


That make me wonder if this issue is happening as a result of my Samba
server being a 32-bit OS install while the HP-UX is a 64-bit install.
That or the NFS/RPC daemons are buggy on the HP-UX side.

In any case, setting strict locking = no on my Samba server makes
things work, so this at least is getting me by.

I've also seen this same phenomenon with Solaris NFS server re-exported
through Samba as well, but don't have any currently that I can test.

Can someone shed some light on what may be happening here?  I'm not
quite able to wrap my mind around the concept and whether or not the
Samba config change is the "right" fix or if I should be looking at
fixing broken NFS servers or something completely different.

Thanks in advance,


More information about the samba mailing list