OS X: mount_nfs & automount behave differently

Question

I have an OS X El Capitan computer and a Linux Mint NFS server, both attached to the same OS X El Capitan Open-Directory Server.

The exports of the server look like this:

/Volumes/PDISK2 10.0.0.0/16(rw,async,no_subtree_check,insecure)
/Volumes/PDISK3 10.0.0.0/16(rw,async,no_subtree_check,insecure)
/Volumes/PDISK4 10.0.0.0/16(rw,async,no_subtree_check,insecure)

On my OS X computer, auto_master looks like this:

#
# Automounter master map
#
+auto_master        # Use directory service
/net            -hosts      -nobrowse,hidefromfinder,nosuid
/home           auto_home   -nobrowse,hidefromfinder
/Network/Servers    -fstab
/-          -static
/- /etc/auto_nfs

And my auto_nfs looks like this:

/Shared/Family          -fstype=nfs,rw,nodev,nosuid,nfc,nolockd,locallocks nfs://10.0.0.11/Volumes/PDISK3/VDISKS/General1/Groups/Family\ Shared
/Shared/Users/christopher   -fstype=nfs,rw,nodev,nosuid,nfc,nolockd,locallocks nfs://10.0.0.11/Volumes/PDISK3/VDISKS/General1/Users/christopher
/Shared/Scratch1        -fstype=nfs,rw,nodev,nosuid,nfc,nolockd,locallocks nfs://10.0.0.11/Volumes/PDISK2/VDISKS/Scratch1

I also manually ran this in /Shared:

mkdir .mnt
mount_nfs -o rw,nodev,nosuid,nfc,nolockd,locallocks 10.0.0.11:Volumes/PDISK3/VDISKS/General1/Groups/Family\ Shared .mnt

I have a file (created with touch) called a in Family Shared.

If I open that file in TextWrangler from the auto-mounted directory, I cannot edit the file because "it is on the locked volume".

If I open that file in TextWrangler from the manually-mounted directory, I can edit and save it it.

Interestingly:

[Defiant:/Shared] christopher% chflags uchg Family/a 
chflags: Family/a: Operation not supported
[Defiant:/Shared] christopher% chflags uchg mnt/a
chflags: mnt/a: Operation not supported

In the finder's Get Info page:

• mnt/a has the "Locked" checkbox greyed-out

• Family/a has the "Locked" checkbox available, but when I check it it unchecks itself.

The result of nfsstat -m is:

/Shared/Family from 10.0.0.11:/Volumes/PDISK3/VDISKS/General1/Groups/Family Shared
  -- Original mount options:
     General mount flags: 0x500018 nodev,nosuid,automounted,nobrowse
     NFS parameters: locallocks,nfc
     File system locations:
       /Volumes/PDISK3/VDISKS/General1/Groups/Family Shared @ 10.0.0.11 (10.0.0.11)
  -- Current mount parameters:
     General mount flags: 0x4500018 nodev,nosuid,automounted,nobrowse multilabel
     NFS parameters: vers=3,tcp,port=2049,nomntudp,hard,nointr,noresvport,negnamecache,callumnt,locallocks,quota,rsize=32768,wsize=32768,readahead=16,dsize=4096,nordirplus,nodumbtimr,timeo=10,maxgroups=16,acregmin=5,acregmax=60,acdirmin=5,acdirmax=60,nomutejukebox,nfc,sec=sys
     File system locations:
       /Volumes/PDISK3/VDISKS/General1/Groups/Family Shared @ 10.0.0.11 (10.0.0.11)
     Status flags: 0x0

/Shared/mnt from 10.0.0.11:/Volumes/PDISK3/VDISKS/General1/Groups/Family Shared
  -- Original mount options:
     General mount flags: 0x18 nodev,nosuid
     NFS parameters: locallocks,nfc
     File system locations:
       /Volumes/PDISK3/VDISKS/General1/Groups/Family Shared @ 10.0.0.11 (10.0.0.11)
  -- Current mount parameters:
     General mount flags: 0x4000018 nodev,nosuid multilabel
     NFS parameters: vers=3,tcp,port=2049,nomntudp,hard,nointr,noresvport,negnamecache,callumnt,locallocks,quota,rsize=32768,wsize=32768,readahead=16,dsize=4096,nordirplus,nodumbtimr,timeo=10,maxgroups=16,acregmin=5,acregmax=60,acdirmin=5,acdirmax=60,nomutejukebox,nfc,sec=sys
     File system locations:
       /Volumes/PDISK3/VDISKS/General1/Groups/Family Shared @ 10.0.0.11 (10.0.0.11)
     Status flags: 0x0

So basically they're the exact same. Except that they're not.

So the questions: Why are they different and how can I fix them?

Also, if I manually mount it using the vers=4.0 option, it appears to work but it freezes on safe.

This question is cross-posted because there are at least two distinct groups who will have encountered this:

• IT professionals who have incorporated Macs into their network (hence ServerFault).

• Power-users/small-businesses who have attempted to do this as well (hence SuperUser).