Sie sind nicht angemeldet.

[gelöst] NFS-Import schlägt mit RPC-Fehler fehl

Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

1

17.06.2014, 22:19

NFS-Import schlägt mit RPC-Fehler fehl

Auf dieser Maschine (auf der ich schreibe) importiere ich seit vielen Jahren ohne Probleme 3 Dateibäume von einem Debian-Server, worauf meine Archive lagern, mit NFSv2. Diese Maschine ist am Ende ihrer Leistungsfähigkeit und es gibt keine großen Platten dafür, weswegen ich eine neue Maschine mit aktuellem Debian (7) als Ersatz aufgesetzt habe. Leider gelingt mir kein Import. Beispielsweise erhalte ich folgende Fehlermeldungen:

Quellcode

 
1
2

er@p2800:~$ showmount -e 2i1800
clnt_create: RPC: Port mapper failure - RPC: Authentication error

oder

Quellcode

 
1
2
3

er@p2800:~$ sudo rpcinfo -p 192.168.192.8
[sudo] password for er: 
rpcinfo: Portmapper kann nicht erreicht werden: rpcinfo: RPC: Fehler bei der Authentifizierung; Ursache = Die Bestätigung des Clients ist zu unsicher
.
Aus diesen Meldungen werde ich nur insoweit schlau als daß ich erkenne, daß der RPC-Dienst nicht richtig funktioniert. Der relevante Abschnitt in /etc/fstab schaut so aus:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#		P450: NFS-Laufwerke (Archiv und /tmp)
# Einhängen nur bei Bedarf (sicherer):
#p450:/tmp/	/mnt-p450tmp	nfs	ro,noauto,noexec,nfsvers=2	0	0
#p450:/arc/-o	/mnt-arc-o	nfs	rw,noauto,noexec,nfsvers=2	0	0
#p450:/arc/-p	/mnt-arc-p	nfs	rw,noauto,noexec,nfsvers=2	0	0
#p450:/arc/-x	/mnt-arc-x	nfs	rw,noauto,noexec,nfsvers=2	0	0
# grundsätzlich einhängen (unsicherer):
p450:/tmp/	/mnt-p450tmp	nfs	ro,auto,noexec,nfsvers=2	0	0
p450:/arc/-o	/mnt-arc-o	nfs	rw,auto,noexec,nfsvers=2	0	0
p450:/arc/-p	/mnt-arc-p	nfs	rw,auto,noexec,nfsvers=2	0	0
p450:/arc/-x	/mnt-arc-x	nfs	rw,auto,noexec,nfsvers=2	0	0
# neuer Server (ersetzt P450):
#2i1800:/tmp/	/mnt-2i1800tmp	nfs	ro,auto,noexec,nfsvers=2	0	0
#2i1800:/arc/-o	/mnt-arc-o	nfs	rw,auto,noexec	0	0
#2i1800:/arc/-p	/mnt-arc-p	nfs	rw,auto,noexec	0	0
#2i1800:/arc/-x	/mnt-arc-x	nfs	rw,auto,noexec	0	0


Es geht um die letzten 4 auskommentierten Zeilen; die nicht auskommentierten beziehen sich auf den alten Server und funktionieren.

Serverseitig (neue Maschine) schaut es so aus:

/etc/exports:

Quellcode

 
1
2
3
4
5
6
7
8

# /etc/exports: the access control list for filesystems which may be exported
/               *.netz(ro,root_squash)
#/tmp           *.netz(rw,root_squash,map_static=/etc/nfs/a4000t.map)
/tmp            *.netz(ro,insecure,all_squash)
/arc/-o         P100(rw,root_squash) S900-L(rw,root_squash,no_subtree_check) PC600(rw,root_squash,no_subtree_check) P2800(rw,root_squash,no_subtree_check)
/arc/-p         P100(rw,root_squash) S900-L(rw,root_squash,no_subtree_check) PC600(rw,root_squash,no_subtree_check) P2800(rw,root_squash,no_subtree_check)
/arc/-x         P100(rw,root_squash) S900-L(rw,root_squash,no_subtree_check) PC600(rw,root_squash,no_subtree_check) P2800(rw,root_squash,no_subtree_check)
#


/etc/hosts.allow:

Quellcode

 
1
2
3
4
5
6
7
8
9

#                       LDAP-Zugriff selektiv erlauben:

#                       RPC-Dienste selektiv erlauben:
portmap:        192.168.192.0/255.255.255.0, 192.168.168.0/255.255.255.0
rpc.mountd:     192.168.192.0/255.255.255.0, 192.168.168.0/255.255.255.0
rpc.ugidd:      192.168.192.0/255.255.255.0

#                       Swat (Samba-Konfiguration):


/etc/services:

Quellcode

 
1
2
3
4
5
6

svn             3690/udp        subversion
mount           4003/udp                # rpc.mountd
mount           4003/tcp                # rpc.mountd
rquotad         4004/udp                # rpc.rquotad
rquotad         4004/tcp                # rpc.rquotad
suucp           4031/tcp                        # UUCP over SSL


/etc/defaults/nfs-common:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# If you do not set values for the NEED_ options, they will be attempted
# autodetected; this should be sufficient for most people. Valid alternatives
# for the NEED_ options are "yes" and "no".

# Do you want to start the statd daemon? It is not needed for NFSv4.
NEED_STATD=yes

# Options for rpc.statd.
#   Should rpc.statd listen on a specific port? This is especially useful
#   when you have a port-based firewall. To use a fixed port, set this
#   this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
#   For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
STATDOPTS="-port 4000 -outgoing-port 4001"

# Do you want to start the idmapd daemon? It is only needed for NFSv4.
NEED_IDMAPD=

# Do you want to start the gssd daemon? It is required for Kerberos mounts.
NEED_GSSD=


Wozu das alles gut sein soll, ist mir nicht so recht klar; das meiste habe ich früher nie gebraucht.
Vielleicht kann mir jemand eine Tip geben, wo es sich zu suchen lohnt, damit es die nächsten 5 Jahre wieder rund läuft, ohne daß ich mich dauernd damit befassen muß.


Diagnose auf der Client-Maschine: siehe oben.

Diagnose auf dem Server:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

2i1800:~# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  59316  nlockmgr
    100021    3   udp  59316  nlockmgr
    100021    4   udp  59316  nlockmgr
    100021    1   tcp  57917  nlockmgr
    100021    3   tcp  57917  nlockmgr
    100021    4   tcp  57917  nlockmgr
    100005    1   udp   4003  mountd
    100005    1   tcp   4003  mountd
    100005    2   udp   4003  mountd
    100005    2   tcp   4003  mountd
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »ebbi97a« (17.02.2017, 19:11)

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

2

18.06.2014, 10:02

Ich hätte als erstes die alte NFS-Version in Verdacht. (Der Client verlangt nach v2). Lass die Option einmal weg.

Was sagt denn

Quellcode

 
1

rpcinfo -u 2i1800 100003


Außerdem sehe ich den RPC-Dienst 100227 (nfs_acl), welcher vielleicht erst noch konfiguriert gehört.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

3

23.06.2014, 08:50

Zitat von »Fredl«

Ich hätte als erstes die alte NFS-Version in Verdacht. (Der Client verlangt nach v2). Lass die Option einmal weg.

Leider ist das ein Irrtum, der aber meiner schlampigen Erklärung geschuldet ist:
Die abgebildete Konfigurationsdatei stellt meinen Arbeitszustand nach erfolglosem Test dar. P450 heißt der alte (NFS-)Server, der nach V2 ausliefert, weil ich früher 2 alte AmigaOS-Systeme mitversorgt hatte, die aber inzwischen das Zeitliche gesegnet haben; der neue Server heißt 2I1800. Damit ich mit der alten Konstellation weiterarbeiten kann, bis eine Lösung zur Umstellung gefunden ist, habe ich die falschen (= nicht funktionierenden) Konfigurationsanweisungen auskommentiert. Dort aber habe ich

Quellcode

 
1

nfsvers=
ganz weggelassen. In Zukunft bin ich nicht mehr auf V2 angewiesen.

Der Aufruf

Quellcode

 
1

rpcinfo -u 2i1800 100003
liefert auf dem NFS-Client:

Quellcode

 
1
2
3

er@p2800:~$ rpcinfo -u 2i1800 100003
rpcinfo: RPC: Fehler des Portmappers - RPC: Fehler bei der Authentifizierung
Das Programm 100003 ist nicht verfügbar


Zitat von »Fredl«

Außerdem sehe ich den RPC-Dienst 100227 (nfs_acl), welcher vielleicht erst noch konfiguriert gehört.

Wo der herkommt habe ich mich auch schon gefragt. Anscheinend habe ich irgendwo was eingetragen, was ich nicht verstanden habe. Nach reichlichem "Googeln" habe ich mich von http://www.linuxmuster.net /wiki/version4:server:nfs leiten lassen, einiges aber nicht verstanden, sondern nur ausgeführt, weil es so dasteht.
_______________________________
Welches System hätten's denn gern?

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

4

17.10.2014, 20:14

Neuer Versuch

Nach Monaten des Stillstands und gezwungen durch die Tatsache, daß der alte Server endgültig voll ist, wage ich einen neuen Anlauf. Dazu habe ich extra einen aktuellen und jungfräulichen Xubuntu-Clientrechner installiert, der noch nicht durch Altlasten versaut ist. Die Konfiguration des Servers habe ich neu eingerichtet und mich ausschließlich auf NFSv4 beschränkt. Dabei habe ich mich von folgenden Buch leiten lassen:

Zitat

Dirk Deimeke, Stefan Kania, Charly Kühnast,
Stefan Semmelroggen, Daniel van Soest
Linux-Server
Das Administrationshandbuch
ISBN 978-3-8362-1879-5
© Galileo Press, Bonn 2012
2., aktualisierte und erweiterte Auflage
, hiervon besonders die Seiten 489-497.

Ich habe das Gefühl, ziemlich weit gekommen zu sein, aber der Erfolg will sich nicht einstellen.

/etc/exports:

Zitat

# NFS-Pseudodateisystem:
/nfs4root 192.168.168.0(ro,sync,insecure,root_squash,no_subtree_check,fsid=0)
# NFS-Freigaben (V4):
/nfs4root/tmp 192.168.192.0(ro,sync,insecure,root_squash,no_subtree_check)
/nfs4root/arc-o 192.168.192.0(ro,sync,insecure,root_squash,no_subtree_check)
/nfs4root/arc-p 192.168.192.0(ro,sync,insecure,root_squash,no_subtree_check)
/nfs4root/arc-x 192.168.192.0(ro,sync,insecure,root_squash,no_subtree_check)

/etc/fstab:

Zitat

# /arc/-p was on /dev/sdb5 during installation
UUID=caeec17c-ad54-4811-bdb8-7937d4510bc1 /arc/-p ext4 defaults 0 2
# /arc/-s was on /dev/sda9 during installation
UUID=3eed050f-9582-4924-b95d-53d160b82c6f /arc/-s ext4 defaults 0 2
# /arc/-x was on /dev/sdb6 during installation
UUID=2e48032b-9746-49c8-9776-a66d72ee77a2 /arc/-x ext4 defaults 0 2
# /arc/-o was on /dev/sdb4 during installation
UUID=8c38cd8a-55bc-4a8f-9341-ea86efa53013 /arc/-o ext4 defaults 0 2

# Einbinden von nfs4root:
/tmp /nfs4root/tmp none rw.bind 0 0
/arc-o /nfs4root/arc-o none rw.bind 0 0
/arc-p /nfs4root/arc-p none rw.bind 0 0
/arc-x /nfs4root/arc-x none rw.bind 0 0

/etc/hosts.allow:

Zitat

# RPC-Dienste selektiv erlauben:
portmap: 192.168.192.0/255.255.255.0, 192.168.168.0/255.255.255.0
rpc.mountd: 192.168.192.0/255.255.255.0, 192.168.168.0/255.255.255.0
rpc.ugidd: 192.168.192.0/255.255.255.0
rpcbind: 192.168.192.0/255.255.255.0, 192.168.168.0/255.255.255.0, 127.0.0.1


Ausgaben diverser Abfragen auf dem Server:

Zitat

~# rpcinfo -p localhost
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 38608 nlockmgr
100021 3 udp 38608 nlockmgr
100021 4 udp 38608 nlockmgr
100021 1 tcp 35489 nlockmgr
100021 3 tcp 35489 nlockmgr
100021 4 tcp 35489 nlockmgr
100005 1 udp 4003 mountd
100005 1 tcp 4003 mountd
100005 2 udp 4003 mountd
100005 2 tcp 4003 mountd

Zitat

~# exportfs -v
/nfs4root 192.168.168.0(ro,wdelay,insecure,root_squash,no_subtree_check,fsid=0)
/nfs4root/tmp 192.168.192.0(ro,wdelay,insecure,root_squash,no_subtree_check)
/nfs4root/arc-o
192.168.192.0(ro,wdelay,insecure,root_squash,no_subtree_check)
/nfs4root/arc-p
192.168.192.0(ro,wdelay,insecure,root_squash,no_subtree_check)
/nfs4root/arc-x
192.168.192.0(ro,wdelay,insecure,root_squash,no_subtree_check)


Und Ausgaben auf dem Client:
Der Rechnername 2i1800 (der irgendwo vorkommt) ist der Server - nicht der Client aus NFS-Sicht!

Zitat

~$ rpcinfo -p 2i1800
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 38608 nlockmgr
100021 3 udp 38608 nlockmgr
100021 4 udp 38608 nlockmgr
100021 1 tcp 35489 nlockmgr
100021 3 tcp 35489 nlockmgr
100021 4 tcp 35489 nlockmgr
100005 1 udp 4003 mountd
100005 1 tcp 4003 mountd
100005 2 udp 4003 mountd
100005 2 tcp 4003 mountd

Zitat

~$ sudo mount -t nfs4 2i1800:/tmp /mnt
mount.nfs4: access denied by server while mounting 2i1800:/tmp

Zitat

~$ mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
/dev/sda8 on /home type ext4 (rw)
/dev/sda6 on /usr type ext4 (rw)
/dev/sda7 on /var type ext4 (rw)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=spittler)


Übrigens - und das ist merkwürdig - lassen sich die NFS-Exporte nicht nur aus dem Client in einem anderen Teilnetz nicht einhängen, sondern auch lokal (auf dem Server selbst nicht) nicht:

Zitat

~# mount -t nfs4 localhost:/. /mnt
mount.nfs4: access denied by server while mounting localhost:/.

Vermutlich ist das ein wichtiger Hinweis, wo der Fehler zu suchen ist, aber mir fehlt die Erleuchtung.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »ebbi97a« (17.10.2014, 20:24) aus folgendem Grund: Mehrere wichtige Ergänzungen zur Klarstellung

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

5

17.10.2014, 21:38

Zitat von »ebbi97a«

access denied by server while mounting 2i1800:/tmp
/tmp steht gar nicht in der Liste der exports

Zitat von »ebbi97a«

~# exportfs -v
/nfs4root 192.168.168.0(ro,w...
Die IP ohne Netzwmaske wird als Host-IP interpretiert. Siehe man-page:

Zitat

single host
You may specify a host either by an abbreviated name recognized be the resolver, the fully qualified domain name, an IPv4 address, ...

IP networks
You can also export directories to all hosts on an IP (sub-) network simultaneously. This is done by specifying an IP address and netmask
pair as address/netmask where the netmask can be specified in dotted-decimal format, or as a contiguous mask length.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

6

18.10.2014, 12:52

Re: Neuer Versuch

Zitat von »Fredl«

/tmp steht gar nicht in der Liste der exports

Das war nur ein Zitierfehler meinerseits (hatte ich weggelassen) -
- aber das war ein Treffer:

Zitat von »Fredl«

Die IP ohne Netzwmaske wird als Host-IP interpretiert. Siehe man-page:

Da hätte ich noch lange suchen müssen; vielen Dank für die Erleuchtung!

Jetzt werden die Verzeichnisse auf dem Client importiert, allerdings fehlt noch der Inhalt (sie werden als leer angezeigt). Da werde ich aber hoffentlich selber weiterkommen; ebenso wie beim Feinschliff (die Zugriffsrechte möchte ich doch nicht so pauschal verteilen).
_______________________________
Welches System hätten's denn gern?

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

7

18.10.2014, 21:20

Zitat von »ebbi97a«

allerdings fehlt noch der Inhalt (sie werden als leer angezeigt
Du hast schon am Server Verzeichnisse ineinander gemountet. Beim Export brauchst du die Option crossmnt, damit die darauf gemounteten Verzeichnisse mitexportiert werden. (oder "nohide"). Siehe 'man exports'
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

8

18.10.2014, 21:50

crossmount?

Zitat von »Fredl«

Du hast schon am Server Verzeichnisse ineinander gemountet. Beim Export brauchst du die Option crossmnt, damit die darauf gemounteten Verzeichnisse mitexportiert werden. (oder "nohide"). Siehe 'man exports'

Damit habe ich schon länger Verständnisprobleme (NFSv2 ohne dieses Basisdateisystem war wesentlich einfacher zu verstehen) und deshalb heute noch andere Anleitungen gelesen. Das Problem war, daß jede Anleitung z.T. erheblich von der anderen abweicht, Dinge herausstellt oder wegläßt und z.T. ganz ohne dieses "nfs4root" auszukommen scheint.

Heute habe ich die Konfigurationsdateien nochmal systematisch durchgearbeit und die Pfade abgeändert, ohne daß sich im Ergebnis was Wesentliches geändert hätte.

Auf dem Server:
/etc/fstab (Auszug):

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# /tmp was on /dev/sda7 during installation
UUID=e005aaa6-a783-4de6-9d05-2f1f544d0c32 /tmp            ext2    defaults        0       2
 … … …
# /arc/-p was on /dev/sdb5 during installation
UUID=caeec17c-ad54-4811-bdb8-7937d4510bc1 /arc/-p         ext4    defaults        0       2
# /arc/-s was on /dev/sda9 during installation
UUID=3eed050f-9582-4924-b95d-53d160b82c6f /arc/-s         ext4    defaults        0       2
# /arc/-x was on /dev/sdb6 during installation
UUID=2e48032b-9746-49c8-9776-a66d72ee77a2 /arc/-x         ext4    defaults        0       2
# /arc/-o was on /dev/sdb4 during installation
UUID=8c38cd8a-55bc-4a8f-9341-ea86efa53013 /arc/-o         ext4    defaults        0       2

# Einbinden von nfs4root:
/tmp	/srv/nfs4root/tmp		none	rw.bind		0	0
/arc-o	/srv/nfs4root/arc-o		none	rw.bind		0	0
/arc-p	/srv/nfs4root/arc-p		none	rw.bind		0	0
/arc-x	/srv/nfs4root/arc-x		none	rw.bind		0	0
# Wozu dient das?

Die Namen sind mit Ausnahme von "/tmp" eigentlich alle eindeutig, obwohl ich nirgends eine Bedingung gefunden habe, daß das so sein müsse. In Beispielen war das z.T. nicht der Fall.
Oben werden also 5 Partitionen explizit eingehängt, wovon 4 per NFS exportiert werden sollen.

/etc/exports (Auszug):

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12

# NFS-Pseudodateisystem:
/srv/nfs4root	192.168.192.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check,fsid=0)
/srv/nfs4root	192.168.168.0/24(ro,sync,insecure,root_squash,no_subtree_check,fsid=0)
# NFS-Freigaben (V4):
/srv/nfs4root/tmp	192.168.192.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
/srv/nfs4root/tmp	192.168.168.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
/srv/nfs4root/arc-o	192.168.192.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
/srv/nfs4root/arc-o	192.168.168.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
/srv/nfs4root/arc-p	192.168.192.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
/srv/nfs4root/arc-p	192.168.168.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
/srv/nfs4root/arc-x	192.168.192.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
/srv/nfs4root/arc-x	192.168.168.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)

Der Export erfolgt in 2 verschiedene Teilnetze.
Dort werden sie zumindest erkannt, aber offenbar werden die falschen Partionen verwendet. Wenn ich auf dem Client-Rechner z.B. versuchsweise "/arc-x" (echter Pfad auf dem Server: "/arc/-x") mit

Quellcode

 
1

sudo mount -t nfs4 2i1800:/arc-x /mnt
einhängen will, schaut es so aus, als wäre das gelungen. Ein Kommando "df -h" auf dem Client zeigt allerdings klipp und klar, daß die (echte) Root-Partition "/" statt "arc-x" eingehangen wurde; das ist zweifelsfrei an der ausgegebenen Größe und dem Füllstand zu erkennen. Als Inhalt wird aber gar nichts angezeigt; mit "ls" scheint sie völlig leer zu sein.

Alle Exporte im obigen Beispiel sind auf dem Server echte Partitionen, die im Dateibaum hängen und keine weiteren Unterpartitionen enthalten.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »ebbi97a« (18.10.2014, 22:03)

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

9

18.10.2014, 22:48

Zitat von »ebbi97a«

# Wozu dient das?

Zitat von »https://wiki.archlinux.org/index.php/NFS«

For security reasons, it is recommended to use an NFS export root which will keep users limited to that mount point only.
Falls du die security anders lösen kannst, würde ich zuerst den einfachsten Weg nehmen:
# /etc/exports
/arc/-o 192.168.192.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
/arc/-o 192.168.168.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
...
(BTW: Bist du auf diese beiden Netzadressen angewiesen? Mit etwas Geschick könnte man zwei getrennte Netze machen, die sich in der exports mittels geeigneter Netzmaske in einer Zeile zusammenfassen ließen.)

Zitat von »ebbi97a«

"df -h" auf dem Client zeigt, daß "/" statt "arc-x" eingehangen wurde; mit "ls" scheint sie völlig leer zu sein.
Nach deiner fstab am Server würde ich das auf einen Konfigurationsfehler zurückführen:
Die Partition ist auf /arc/-o gemountet.

Zitat von »ebbi97a«

# fstab:
# UUID=8c38cd8a-55bc-4a8f-9341-ea86efa53013 /arc/-o ext4 defaults 0 2
Hier bind-mountest du das (nicht existente Verzeichnis "/arc-o" auf "/srv/nfs4root/arc-o":

Zitat von »ebbi97a«

# fstab:
/arc-o /srv/nfs4root/arc-o none rw.bind 0 0
Und dieses exportierst du:

Zitat von »ebbi97a«

# exports:
/srv/nfs4root/arc-o 192.168.192.0/255.255.255.0(ro,sync,insecure,root_squash,no_subtree_check)
Hier wir kein Fehler mehr gemeldet. Im vorigen Schritt wahrscheinlich schon.
Beim NFS-mount wird auch keiner gemeldet, weil der Export an sich gültig und erlaubt ist. Nur ist in dem Verzeichnis nix drin, weil das darunter liegende Verzeichnis nicht existiert. Schau in die Logs vom Server. Ziemlich am Anfang, wenn die fstab abgearbeitet wird, müssten ein paar Meldungen wegen "/arc-o" stehen.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

10

19.10.2014, 21:19

Morgen früh…

Bin gerade erst heimgekommen und zu müde, das heute noch zu verstehen. Morgen früh denke ich alles noch mal durch:

Zitat von »Fredl«

Nach deiner fstab am Server würde ich das auf einen Konfigurationsfehler zurückführen: Die Partition ist auf /arc/-o gemountet.

Hier bind-mountest du das (nicht existente Verzeichnis "/arc-o" auf "/srv/nfs4root/arc-o":

Beim NFS-mount wird auch keiner gemeldet, weil der Export an sich gültig und erlaubt ist. Nur ist in dem Verzeichnis nix drin, weil das darunter liegende Verzeichnis nicht existiert. Schau in die Logs vom Server. Ziemlich am Anfang, wenn die fstab abgearbeitet wird, müssten ein paar Meldungen wegen "/arc-o" stehen.

/arc/-o ist der absolute (echte!) Pfad des zu exportierenden Verzeichnisses; es ist eine eigenständige Partition.
/arc-o ist der Exportname, den ich ihm geben will. Ich habe die Anleitung so verstanden, daß man an dieser Stelle einen eindeutigen Namen dafür erfinden muß. Möglicherweise war das ein Fehler.
Die Logs werde ich durcharbeiten, nach dem ich das alles nochmal aufgerufen habe.

Danke erst mal - jetzt habe ich wieder Hoffnung für morgen. Einen gemachten Fehler zu finden ist immer viel befriedigender, als mit einer Art von unverständlicher Magie das Problem zum Verschwinden zu kriegen. Im ersten Fall lernt man was dazu, im zweiten Fall bleibt alles rätselhaft. Ich hoffe auf einen Konfigurationsfehler. ;)
___________________________________________________________________________________________________________________________________________________________

1 Tag später:


Das nochmalige Lesen hat keine neuen Erkenntnisse gebracht; nach wie vor bin ich der Meinung, daß die gewählten Namen zulässig sind und an den richtigen Stellen stehen. Die Hoffnung auf die Logdateien hat wieder (schon anfangs hatte ich nach solchen Ausschau gehalten) getrogen: es ist so gut wie nichts zu finden. Auch in /etc habe ich weder Konfigurationsdateien von NFS mit Vorgaben zum Log noch passende Anweisungen für den logd gefunden.

Einzige Lebenszeichen:

/var/log/dmesg:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

[   10.820380] kjournald starting.  Commit interval 5 seconds
[   10.820684] EXT3-fs (sdb2): using internal journal
[   10.820692] EXT3-fs (sdb2): mounted filesystem with ordered data mode
[   10.892365] EXT4-fs (sdb7): mounted filesystem with ordered data mode. Opts: (null)
[   10.980546] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[   11.134303] EXT4-fs (sda10): mounted filesystem with ordered data mode. Opts: (null)
[   11.427507] EXT4-fs (sdb5): mounted filesystem with ordered data mode. Opts: (null)
[   11.639799] EXT4-fs (sda9): mounted filesystem with ordered data mode. Opts: (null)
[   11.830194] EXT4-fs (sdb6): mounted filesystem with ordered data mode. Opts: (null)
[   11.981559] EXT4-fs (sdb4): mounted filesystem with ordered data mode. Opts: (null)
[   12.891499] tg3 0000:03:00.0: irq 45 for MSI/MSI-X
[   12.925768] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   14.530164] tg3 0000:03:00.0: eth0: Link is up at 100 Mbps, full duplex
[   14.530171] tg3 0000:03:00.0: eth0: Flow control is on for TX and on for RX
[   14.531102] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   15.780462] RPC: Registered named UNIX socket transport module.
[   15.780467] RPC: Registered udp transport module.
[   15.780471] RPC: Registered tcp transport module.
[   15.780474] RPC: Registered tcp NFSv4.1 backchannel transport module.          <-------
[   15.834270] FS-Cache: Loaded
[   15.867843] FS-Cache: Netfs 'nfs' registered for caching
[   15.879162] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).          <-------

/var/log/kern.log

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Oct 20 07:43:21 2i1800 kernel: [   14.531102] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Oct 20 07:43:21 2i1800 kernel: [   15.780462] RPC: Registered named UNIX socket transport module.
Oct 20 07:43:21 2i1800 kernel: [   15.780467] RPC: Registered udp transport module.
Oct 20 07:43:21 2i1800 kernel: [   15.780471] RPC: Registered tcp transport module.
Oct 20 07:43:21 2i1800 kernel: [   15.780474] RPC: Registered tcp NFSv4.1 backchannel transport module.          <-------
Oct 20 07:43:21 2i1800 kernel: [   15.834270] FS-Cache: Loaded
Oct 20 07:43:21 2i1800 kernel: [   15.867843] FS-Cache: Netfs 'nfs' registered for caching          <-------
Oct 20 07:43:21 2i1800 kernel: [   15.879162] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).          <-------
Oct 20 07:43:21 2i1800 kernel: [   17.335578] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory          <-------
Oct 20 07:43:21 2i1800 kernel: [   17.340481] NFSD: starting 90-second grace period          <-------
Oct 20 07:43:23 2i1800 kernel: [   19.959455] lp0: using parport0 (interrupt-driven).
Oct 20 07:43:23 2i1800 kernel: [   19.972094] ppdev: user-space parallel port driver
Oct 20 07:43:24 2i1800 kernel: [   23.026408] postgres (2538): /proc/2538/oom_adj is deprecated, please use /proc/2538/oom_score_adj instead.
Oct 20 07:43:26 2i1800 kernel: [   25.064025] eth0: no IPv6 routers present
Oct 20 08:03:42 2i1800 kernel: [ 1241.123873] device-mapper: uevent: version 1.0.3
Oct 20 08:03:42 2i1800 kernel: [ 1241.124173] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
Oct 20 08:03:46 2i1800 kernel: [ 1245.528436] EFI Variables Facility v0.08 2004-May-17
Oct 20 08:03:46 2i1800 kernel: [ 1245.733095] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
Oct 20 08:03:46 2i1800 kernel: [ 1245.733619] SGI XFS Quota Management subsystem
Oct 20 08:03:46 2i1800 kernel: [ 1245.736967] JFS: nTxBlock = 8192, nTxLock = 65536
Oct 20 08:03:46 2i1800 kernel: [ 1245.749473] NTFS driver 2.1.30 [Flags: R/W MODULE].
Oct 20 08:03:46 2i1800 kernel: [ 1245.759221] QNX4 filesystem 0.2.3 registered.
Oct 20 08:03:46 2i1800 kernel: [ 1245.775530] Btrfs loaded
Oct 20 08:03:46 2i1800 kernel: [ 1245.778965] fuse init (API version 7.17)

/var/log/messages:

Quellcode

 
1
2
3
4
5
6
7
8

Oct 19 06:49:17 2i1800 kernel: [52730.308536] nfsd: last server has exited, flushing export cache
Oct 20 07:43:21 2i1800 kernel: [   15.867843] FS-Cache: Netfs 'nfs' registered for caching
Oct 20 07:43:21 2i1800 kernel: [   15.879162] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Oct 20 07:43:21 2i1800 kernel: [   17.335578] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
2i1800:/var/log# cat /var/log/messages | grep NFS
Oct 20 07:43:21 2i1800 kernel: [   15.780474] RPC: Registered tcp NFSv4.1 backchannel transport module.
Oct 20 07:43:21 2i1800 kernel: [   17.335578] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Oct 20 07:43:21 2i1800 kernel: [   17.340481] NFSD: starting 90-second grace period

/var/log/syslog:

Quellcode

 
1
2
3
4
5
6
7
8

Oct 20 07:43:21 2i1800 kernel: [   15.780474] RPC: Registered tcp NFSv4.1 backchannel transport module.
Oct 20 07:43:21 2i1800 kernel: [   17.335578] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Oct 20 07:43:21 2i1800 kernel: [   17.340481] NFSD: starting 90-second grace period
2i1800:/var/log# cat /var/log/syslog | grep nfs
Oct 19 06:49:17 2i1800 kernel: [52730.308536] nfsd: last server has exited, flushing export cache
Oct 20 07:43:21 2i1800 kernel: [   15.867843] FS-Cache: Netfs 'nfs' registered for caching
Oct 20 07:43:21 2i1800 kernel: [   15.879162] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Oct 20 07:43:21 2i1800 kernel: [   17.335578] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory



Auf dem Client habe ich allerdings heute was gefunden, was in eine ganz andere Richtung weist:

/var/log/syslog:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Oct 20 19:02:16 2A1600 kernel: [22959.505602] NFS: Registering the id_resolver key type
Oct 20 19:02:16 2A1600 kernel: [22959.505807] Key type id_resolver registered
Oct 20 19:02:16 2A1600 kernel: [22959.505816] Key type id_legacy registered
Oct 20 19:02:16 2A1600 kernel: [22959.537987] RPC: AUTH_GSS upcall failed. Please check user daemon is running.          <-------
Oct 20 19:02:16 2A1600 rpc.idmapd[496]: nss_getpwnam: name 'root@netz' does not map into domain 'localdomain'          <-------
Oct 20 19:02:17 2A1600 kernel: [22960.172954] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
Oct 20 19:02:17 2A1600 kernel: [22960.175322] sd 4:0:0:0: [sdb] Asking for cache data failed
Oct 20 19:02:17 2A1600 kernel: [22960.175332] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Oct 20 19:03:08 2A1600 kernel: [23011.888923] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
Oct 20 19:03:08 2A1600 kernel: [23011.891288] sd 4:0:0:0: [sdb] Asking for cache data failed
Oct 20 19:03:08 2A1600 kernel: [23011.891298] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Oct 20 19:04:00 2A1600 kernel: [23063.601079] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
Oct 20 19:04:00 2A1600 kernel: [23063.603321] sd 4:0:0:0: [sdb] Asking for cache data failed
Oct 20 19:04:00 2A1600 kernel: [23063.603331] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Oct 20 19:04:52 2A1600 kernel: [23115.313070] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
Oct 20 19:04:52 2A1600 kernel: [23115.315311] sd 4:0:0:0: [sdb] Asking for cache data failed
Oct 20 19:04:52 2A1600 kernel: [23115.315321] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Oct 20 19:05:44 2A1600 kernel: [23167.024855] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
Oct 20 19:05:44 2A1600 kernel: [23167.027095] sd 4:0:0:0: [sdb] Asking for cache data failed
Oct 20 19:05:44 2A1600 kernel: [23167.027106] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Oct 20 19:06:35 2A1600 kernel: [23218.737010] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
Oct 20 19:06:35 2A1600 kernel: [23218.739253] sd 4:0:0:0: [sdb] Asking for cache data failed
Oct 20 19:06:35 2A1600 kernel: [23218.739263] sd 4:0:0:0: [sdb] Assuming drive cache: write through

und /var/log/auth.log:

Quellcode

 
1
2
3
4
5
6

Oct 20 19:02:16 2A1600 sudo: zensiert : TTY=pts/1 ; PWD=/home/zensiert ; USER=root ; COMMAND=/bin/mount -t nfs4 2i1800:/arc-x /mnt
Oct 20 19:02:16 2A1600 sudo: pam_unix(sudo:session): session opened for user root by zensiert(uid=0)
Oct 20 19:02:16 2A1600 sudo: pam_unix(sudo:session): session closed for user root
Oct 20 19:06:39 2A1600 sudo: zensiert : TTY=pts/10 ; PWD=/home/spittler ; USER=root ; COMMAND=/usr/bin/mc
Oct 20 19:06:39 2A1600 sudo: pam_unix(sudo:session): session opened for user root by zensiert(uid=0)
Oct 20 19:06:55 2A1600 sudo: pam_unix(sudo:session): session closed for user root


Meine lokale Domain heißt wirklich netz und nicht localdomain.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »ebbi97a« (20.10.2014, 19:22)

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

11

20.11.2016, 12:07

fast gelöst

Hätte nicht gedacht, daß ich länger als 2 Jahre brauche, um das NFSv4 in den Griff zu kriegen; habe eben zu viele Großbaustellen gleichzeitig offen.
Vorgestern habe ich das Problem wegen einer Totalblockade meiner Arbeiten durch ein neues Unglück wieder in Angriff genommen und nach vielem Lesen und Rätselraten kam gestern spätabends der Durchbruch: jetzt kann ich die wichtigen Archive auf dem Archivserver den anderen Clients im Netz 192.168.168.0 zur Verfügung stellen und diese können lesen und (so gewünscht) schreiben.

Zum Abschluß bitte ich noch um Hilfe, wie ich einen einzelnen Rechner aus diesem Subnetz ausschließen kann: 192.168.168.66 soll keinen Zugriff haben oder wenigstens keinen schreibenden. Füher hätte ich den in die /etc/hosts.deny eingetragen - aber das scheint ja alles nicht mehr so richtig zu gelten. Die Welt ist sehr verworren geworden.


So weit zur Sache. Jetzt noch ein bischen Geschwafel für Interessierte, warum das so unglaublich schwierig war:
Bei der Suche nach Beschreibungen war die erste Schwierigkeit, daß viele Fundstellen sich auch auf oder nur auf NFSv2 oder v3 bezogen, das aber nicht klar zu erkennen war. Vollkommen logisch, denn wer hätte damals wissen sollen, daß v4 ganz anders wird. Am meisten haben aber die verwendeten Beispiele in die Irre geführt; in meinem Fall war das die Anlage des sog. Pseudodateisystems um nfs4root und seine Einbindung.

Es ging damit los, daß der NFS-Server mit provisorischer Einrichtung (= händischem Mount aller Verzeichnisse) relativ schnell funktionierte und richtige Inhalte zeigte. Nach Konfiguration eines Muster-Clients waren diese exportierten Verzeichnisse aber scheinbar leer. Und als ich die Einbindung auf dem Server durch Eintrag in /etc/fstab dauerhaft machen wollte, wurde es ganz verwirrend. Neuladen des Servers ging noch ohne Fehlermeldungen ab, aber es funktionierte nichts; Neustart des Serverbetriebssystems hing sich auf. Ich mußte wieder zurück und händisch mounten und den Fehler an anderer Stelle suchen. Nach vielen Stunden bin ich darauf gekommen, daß die abgedruckten Beispiele alle zu banal sind - obwohl durchaus praxisnah und vernünftig. Da will einer beispielsweise sein Homeverzeichnis exportieren, welches natürlich /home mit absolutem Pfadnamen heißt; es kann ja gar nicht anders. Und den Export nennt er dann auch home. Wenn man dann seine eigenen Daten in analoger Weise aufbaut, kann eigentlich gar nichts schief gehen. Ich hatte aber triftige Gründe, meine 3 Exports auf Server- und auf Client-Seite verschieden zu benennen und stand sofort vor der Frage, was (welcher Name oder Pfad) wohin gehört - und habe natürlich prompt falsch geraten, weil es mir aber einleuchtend erschien. Als nun überhaupt nichts ging und viele andere Kombinationen durchprobiert waren, kam ich endlich auf die Idee, linke und rechte Seite im Abschnitt nfs4root der /etc/fstab zu vertauschen; irgendwann paßte dann alles.

Beim 2. Mal würde ich das nicht mehr besonders schwierig finden, aber wenn man das völlig neue Konzept noch nicht verstanden hat, ständig durch die Vorgeschichte verwirrt wird und Analogien nicht richtig erkennen kann ist es fast unmöglich.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ebbi97a« (20.11.2016, 12:12)

Ähnliche Themen

Verwendete Tags

exports, fstab, mount, NFS, RPC