OS X: mount_nfs & automount verhalten sich anders

Ich habe einen OS X El Capitan-Computer und einen Linux Mint NFS-Server, die beide an denselben OS X El Capitan-Open-Directory-Server angeschlossen sind.

Die Exporte des Servers sehen folgendermaßen aus:

/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) 

Auf meinem OS X-Computer sieht auto_master folgendermaßen aus:

# # 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 

Und mein auto_nfs sieht so aus:

/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 

Ich habe das auch manuell ausgeführt 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 

Ich habe eine Datei (erstellt mit touch) genannt ain Family Shared.

Wenn ich diese Datei in TextWrangler aus dem automatisch eingebundenen Verzeichnis öffne, kann ich die Datei nicht bearbeiten, da sie sich auf dem gesperrten Volume befindet.

Wenn ich diese Datei in TextWrangler aus dem manuell eingebundenen Verzeichnis öffne, kann ich sie bearbeiten und speichern.

Interessant:

[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 der Get Info-Seite des Finders:

• mnt/a hat das Kontrollkästchen "Gesperrt" ausgegraut

• Family/a hat das Kontrollkästchen "Gesperrt" verfügbar, aber wenn ich es ankreuze, wird es deaktiviert.

Das Ergebnis von nfsstat -mist:

/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 

Im Grunde sind sie genau gleich. Nur dass sie es nicht sind.

Also die Fragen: Warum unterscheiden sie sich und wie kann ich sie beheben?

Wenn ich es manuell mit der Option vers = 4.0 mounte, scheint es zu funktionieren, friert aber sicher ein.

Diese Frage ist cross-posted, da es mindestens zwei verschiedene Gruppen gibt, denen dies begegnet ist:

• IT-Experten, die Macs in ihr Netzwerk integriert haben (daher ServerFault).

• Power-User / kleine Unternehmen, die dies ebenfalls versucht haben (daher SuperUser).