Logged In: YES 
user_id=390363

Perhaps a config file option?
NFSLOCKSUPPORT=1

It's a mess, but these days I'd say that fcntl()
locking (which Python slightly misleadingly calls
fcntl.lockf) is more portable than flock() (which
Python even more misleadingly calls fcntl.flock).

 * The only Unixes without fcntl() style locking
 are pre-4.4BSD, and pre-SysV. (fcntl() appeared
 in the SVID, was standardized by /usr/group,
 XPG4, and then Posix).
 http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html

 * flock() only appeared in 4.2BSD, it exists
 only on the BSD side of the universe.  Many
 systems tended to support both flock() and
 fcntl(), with dire warnings that never the twain
 should mix.  But not all: System V before SVR4
 (and some SVR4) don't support flock(), HPUX,
 RISCOS don't.  I'd bet that some AIX didn't
 either.

 * flock has never worked on NFS.

 * fcntl kind of worked on NFS, but had a bad
 reputation because of bugs and performance
 issues in rpc.lockd and rpc.statd.  In recent years,
 it seems to have improved, probably because the
 databases use this locking. (e.g. sqlite only supports
 fcntl locking)
http://www.washington.edu/imap/documentation/locking.txt.html
 has many of the ugly details.

 * Python implements fcntl.lockf with fcntl()
 locking everywhere.  It implements fcntl.flock
 with flock() if HAVE_FLOCK is defined, but
 otherwise uses fcntl() style locking.

Both flock() and fcntl() have long and ugly
histories, I dislike both and generally prefer
ancient-style hard-link or mkdir-style locking,
even though one has to write manual stale lock
detection/cleanup.