AIX und das Network File System NFS

NFS Überprüfungen

# nfsstat -s NFS-Server prüfen

# nfsstat -c NFS-Client prüfen

# entstat -d <device> Netzwerkadapter prüfen

(Siegert 372f)

NFS Probleme

Datenübertragunsrate bricht auf NFS Mount ein

There is not enough memory available now

NFS access failed for server xxxx error 7 (RPC: Authentication error)

nfsmnthelp: 1831-019 <targetserver>: System call error number -1

NFS Probleme Checkliste IBM

NFS Sicherheitsproblem

Datenübertragunsrate bricht auf NFS Mount ein

Beim übertragen großer Dateien mittels nfs bricht die Datenübertragungsrate meist nach kurzer Zeit ein. 'Groß' bezeichnet dabei Datenmengen, die größer sind, als der physikalisch vorhandene RAM der Maschine, von der die Daten kommen. Die Datentransferrate bricht ein, sobald der Speicher des Client voll ist, denn der VMM muß LRUD aufrufen um Speicherseiten freizuräumen, damit weiter in den Speicher geschrieben werden kann.

Ab AIX 5.2 kann man das ändern. Während die Daten auf den NFS Server geschrieben werden ruft man in Intervallen nfsstat auf. Wenn die Zahl der (nfs-) V3 commit calls etwa gleich stark ansteigt, wie die V3 write calls, besteht das Problem sehr wahrscheinlich.  Um zu sehen, wieviel Daten gleichzeitig übertragen werden kann man netstat -I oder topas verwenden. Abhilfe schafft die neue mount-Option comebehind. Also Dateisystem abhängen, dann neu mounten

# mount -o combehind server_hostname:/remote_mount_point /mnt

<Top>

There is not enough memory available now

Das AIX NFS unterstützt ACLs und benutzt dafür einen RPC. Wenn auf NFS-gemounteten Laufwerken bei einer Aktion wie Nutzung des vi oder einem einfachen cp AIX NFS die Rückmeldung "There is not enough  memory available now" kommt, ist meist ein Problem mit NFS die Ursache. Wenn alles richtig funktioniert sieht das z.B. so aus:

# mount -vnfs server:/nfshome /mnt

# cd /mnt/johndoe

# cp -p .profile /tmp/.profile.test

# cd ~

# umount /mnt

Im nächsten Beispiel das für Kombination von 5.1 ML0 bis ML3 und 5.2 ML0 bis ML1 gilt werden die erweiterten Rechte beim mounten gesetzt und der Kopiervorgang schlägt fehl. Genauso kann aber schon ein simples ls auf die Nase fallen:

# mount -vnfs -o acl server:/nfshome /mnt

# cd /mnt/johndoe

# cp -p .profile /tmp/.profile.test

cp: .profile: There is not enough memory available now.

#

Unter AIX 5L ist als default -o noacl für den mount bereits aktivert. Wenn jedoch die acl Option aktiv ist, kommt es zur beschriebenen Fehlermeldung.

Unter 5.2 gibt es einen APAR IY44190, der das Problem behebt, er kann separat installiert werden, bzw. ist ab 5.2 ML2 enthalten.

(0)5.2server:/ 104$ instfix -ik IY44190 -a

IY44190 Abstract: nfs acl's fail on 64 bit kernel

IY44190 Symptom Text:

On a 64 bit kernel nfs server:

# export -i -o rw,root=<hostname>,

access=<hostname> /tmp/stub

# mount -o acl <hostname>:/tmp/stub /mnt

# touch foo

# cp -p foo foo2

cp: foo: There is not enough memory available now.

---------------------------

All filesets for IY44190 were found.

Mit 5.1 ML4 und ML5 tritt der Fehler etwas anders wieder auf, das explizite wegnehmen von ACL hilft hier leider nicht mehr. Es muß der APAR IY47101 eingespielt werden. (Abstract: JFS2 READDIR() CAN BEHAVE UNPREDICTABLY)

<Top>

NFS access failed for server [...]: error 7 (RPC: Authentication error)

Diese Fehlermeldung kann aus einer Reihe von mehreren Gründen auftreten. Die einfachste Lösung ist, daß die UID des Benutzers, der gerade versucht auf den NFS Export zuzugreifen, unbekannt ist und der Zugriff anonymer user mit anon=-1 verboten wurde. In diesem Fall schlägt schon ein einfaches ls fehl, der Zugriff wird abgewiesen:

# ls /home/nfshome

ls: /home/nfshome: There is an input or output error.

NFS access failed for server [...]: error 7 (RPC: Authentication error)

Exakt dieselbe Fehlermeldung trifft root wenn anon=-1 gesetzt wurde und der Zugriff von root auf dieses Verzeichnis nicht ausdrücklich in der exports mit angegeben ist.

<Top>

nfsmnthelp: 1831-019 <targetserver>: System call error number -1

Diese Fehlermeldung kann darauf hinweisen, daß der NFS Server den Namen des Client nicht auflösen kann.

# mount XXXXX:/export/script1 /mnt

nfsmnthelp: 1831-019 XXXXX: System call error number -1.

mount: 1831-008 giving up on:

XXXXX:/export/script1

System call error number -1.

Prüfen, ob der Client in der /etc/hosts des NFS Servers vorhanden ist.

<Top>

NFS Sicherheitsproblem

Bei der Konfiguration eines NFS Exports auf einem AIX Server soll ein Zugriff durch anonyme Benutzer unmöglich gemacht werden, indem  man bei den Exportoptionen den Wert für anon auf -1 setzt. Aus der man page für mknfsexp: "-a UID Uses the UID variable as the effective user ID only if a request comes from an unknown user. The default value of this option is -2.

Note: Root users (UID 0) are always considered unknown by the NFS server, unless they are included in the root option. Setting the value of UID to -1 disables anonymous access." Das heißt, Zugriffe von unbekannten Benutzern werden bei anon=-1 also komplett zurückgewiesen. Aber stimmt das auch?

Eine so angelegter Export sieht dann z.B. so aus:

root@sapsrv-002:/>oslevel -s

6100-04-02-1007

root@sapsrv-002:/>

root@sapsrv-002:/>cat /etc/exports

/usr/sap/TRD/doyle -sec=sys:krb5p:krb5i:krb5:dh,rw,access=sapsrv-sap1,root=sapsrv-sap1

/home/sapadm/import_files -anon=-1,sec=sys:krb5p:krb5i:krb5:dh,rw,root=sapsrv-ogo05

Die Exports selbst sehen genau so aus, wie sie definiert wurden:

root@sapsrv-002:/>exportfs -v

/usr/sap/TRD/doyle -sec=sys:krb5p:krb5i:krb5:dh,rw,access=sapsrv-sap1,root=sapsrv-sap1

/home/sapadm/import_files -anon=-1,sec=sys:krb5p:krb5i:krb5:dh,rw,root=sapsrv-ogo05

root@sapsrv-002:/>

Wir kennen nun die Export Optionen. Das /home/sapadm/import_files Verzeichniss sollte nicht von einem auf dem NFS Server unbekannten Benutzer gemounted werden können. Es funktioniert jedenfalls nicht von einem Windows PC wenn man z.B. den Reflection NFS Client verwendet. Anders sieht es aus, wenn man die Windows Services for UNIX Version 3.5 verwendet. Diese installieren im Windows PC (hier im Beispiel ein deutsches Windows XP mit SP3) u.a. einen NFS Client (Dienst) und eine Kornshell. In dieser Interix KSH nutzen wir nun NFS:

Welcome to the Interix UNIX utilities.

DISPLAY=localhost:0.0

$ PD KSH v5.2.13 97/10/27 [Interix: 2003/11/07][i18n]

$

$ rpcinfo -p sapsrv-002

program version protocol port

--------------------------------------------------

100000 4 udp 111 portmapper

100000 3 udp 111 portmapper

100000 2 udp 111 portmapper

100000 4 tcp 111 portmapper

100000 3 tcp 111 portmapper

100000 2 tcp 111 portmapper

150001 1 udp 32773 pcnfsd

150001 2 udp 32773 pcnfsd

100003 2 udp 2049 nfs

100003 3 udp 2049 nfs

100003 2 tcp 2049 nfs

100003 3 tcp 2049 nfs

100003 4 tcp 2049 nfs

200006 1 udp 2049

200006 4 udp 2049

200006 1 tcp 2049

200006 4 tcp 2049

100005 1 tcp 32773 mountd

100005 2 tcp 32773 mountd

100005 3 tcp 32773 mountd

100005 1 udp 32786 mountd

100005 2 udp 32786 mountd

100005 3 udp 32786 mountd

400005 1 udp 32787

100021 1 udp 32788 nlockmgr

100021 2 udp 32788 nlockmgr

100021 3 udp 32788 nlockmgr

100021 4 udp 32788 nlockmgr

100021 1 tcp 32774 nlockmgr

100021 2 tcp 32774 nlockmgr

100021 3 tcp 32774 nlockmgr

100021 4 tcp 32774 nlockmgr

100024 1 tcp 32775 status

100024 1 udp 32791 status

100133 1 tcp 32775

100133 1 udp 32791

200001 1 tcp 32775

200001 1 udp 32791

200001 2 tcp 32775

200001 2 udp 32791

$

Mit der Anzeige ist es aber nicht getan. Ohne eine Benutzerauthentifizierung gegen den NFS Server kann dieser Client jeden NFS Export lokal mounten!

Sicht vom AIX Server, wer hat was gemounted?

root@sapsrv-002:/>showmount -a

sapsrv-sap1:/usr/sap/TRD/doyle

root@sapsrv-002:/>

Es existiert zunächst nur ein Mount von einem anderen AIX Server aus. Aus der Windows SFU Kornshell mounten wir nun das Verzeichnis ohne Benutzerangabe. (Derselbe Effekt wird auch erreicht wenn man als Option anon als User vorgibt.) Anschließend sieht man, daß das SFU NFS den Mount mit der default UID von -2 herstellt. Den anonymen Mount hatten wir mit anon=-1 aber ausdrücklich verboten.

$ mount sapsrv-002:/home/sapadm/import_files w:

w: is now successfully connected to sapsrv-002:/home/sapadm/import_files

The command completed successfully.

$ mount

Local Remote Properties

-------------------------------------------------------------------------------

w:         \\sapsrv-002\home\sapadm\import_~ UID=-2, GID=-2

rsize=32768, wsize=32768

mount=soft, timeout=0,8

retry=1, locking=yes

fileaccess=755, lang=ANSI

casesensitive=no

$

Der Windows Benutzer ist auf dem AIX Server unbekannt, AD oder LDAP ist zwischen Windows und UNIX nicht im Einsatz. Also wie kann das sein? Auf dem AIX NFS Server sieht man, daß tatsächlich ein mount dazugekommen ist. Der Name für den Windows PC "unix1" wird anscheinend von SFU gesetzt.

root@sapsrv-002:/>showmount -a

sapsrv-sap1:/usr/sap/TRD/doyle

sapsrv-unix1.zentrale.dace:/home/sapadm/import_files

root@sapsrv-002:/>

Das gemountede Dateisystem ist auf dem Windows PC im Dateiexplorer sichtbar inklusive aller Dateien. Für alle Dateien besteht Leseberechtigung. Bis dahin ist es nur ärgerlich, daß jemand etwas sehen kann was er nicht sehen soll und darf. Wenn jetzt aber noch (wie in der Praxis geschehen) dazukommt, daß ein Verzeichnis / eine Datei mit 777 ausgestattet ist, kann der nichtberechtigte unbekannter Benutzer vom Windows PC aus ohne Authentifizierung mit diesem Verzeichnis und den Daten tun und lassen was er will.

Ein identisches Verhalten legt der NFS Server an den Tag wenn von einem anderen AIX Server ein unbekannter Benutzer, der jedoch zur Gruppe "system" gehört, den NFS mount herstellt.

Zusammenfassung. Wenn

dann funktioniert die  NFS anon=-1 Option auf AIX nicht so, wie man es erwartet. In beiden Fällen kann der nichtbefugte Benutzer die Dateien lesen. Der Lesezugriff scheint sich so darzustellen als sei read-mostly konfiguriert (d.h. Leserecht für Others) indem anon=-2 gesetzt wird. Und in der Tat zeigt der mount in der SFU Shell als UID und GID -2 an.

Wenn es die Dateirechte zulassen kann der nicht authentifizierte Benutzer sogar schreiben/löschen etc.  

<Top>