PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NFS-Mount klappt nicht



smartysmart34
04.04.11, 20:27
Hallo zusammen,

ich habe hier einen Server, der zwei NFS-Freigaben exportiert.

/etc/exports:

# See the exports(5) manpage for a description of the syntax of this file.
# This file contains a list of all directories that are to be exported to
# other computers via NFS (Network File System).
# This file used by rpc.nfsd and rpc.mountd. See their manpages for details
# on how make changes in this file effective.
/mnt/local/fileshares/public 192.168.2.0/24(rw,sync,root_squash)
/mnt/local/fileshares/private/martin 192.168.2.0/24(rw,sync,root_squash)


Über die hosts.allow bilde ich mir ein, die Rechner in meinem Netz darauf berechtigt zu haben (wobei ich den Eintrag für nfsd gerade versuchsweise aufgenommen habe):


# /etc/hosts.allow
# See 'man tcpd' and 'man 5 hosts_access' for a detailed description
# of /etc/hosts.allow and /etc/hosts.deny.
#
# short overview about daemons and servers that are built with
# tcp_wrappers support:
#
# package name | daemon path | token
# ----------------------------------------------------------------------------
# ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port>
# quota | /usr/sbin/rpc.rquotad | rquotad
# tftpd | /usr/sbin/in.tftpd | in.tftpd
# portmap | /sbin/portmap | portmap
# The portmapper does not verify against hostnames
# to prevent hangs. It only checks non-local addresses.
#
# (kernel nfs server)
# nfs-utils | /usr/sbin/rpc.mountd | mountd
# nfs-utils | /sbin/rpc.statd | statd
#
# (unfsd, userspace nfs server)
# nfs-server | /usr/sbin/rpc.mountd | rpc.mountd
# nfs-server | /usr/sbin/rpc.ugidd | rpc.ugidd
#
# (printing services)
# lprng | /usr/sbin/lpd | lpd
# cups | /usr/sbin/cupsd | cupsd
# The cupsd server daemon reports to the cups
# error logs, not to the syslog(3) facility.
#
# (Uniterrupted Power Supply Software)
# apcupsd | /sbin/apcupsd | apcupsd
# apcupsd | /sbin/apcnisd | apcnisd
#
# All of the other network servers such as samba, apache or X, have their own
# access control scheme that should be used instead.
#
# In addition to the services above, the services that are started on request
# by inetd or xinetd use tcpd to "wrap" the network connection. tcpd uses
# the last component of the server pathname as a token to match a service in
# /etc/hosts.{allow,deny}. See the file /etc/inetd.conf for the token names.
# The following examples work when uncommented:
#
#
# Example 1: Fire up a mail to the admin if a connection to the printer daemon
# has been made from host foo.bar.com, but simply deny all others:
# lpd : foo.bar.com : spawn /bin/echo "%h printer access" | \
# mail -s "tcp_wrappers on %H" root
#
#
# Example 2: grant access from local net, reject with message from elsewhere.
# in.telnetd : ALL EXCEPT LOCAL : ALLOW
# in.telnetd : ALL : \
# twist /bin/echo -e "\n\raccess from %h declined.\n\rGo away.";sleep 2
#
#
# Example 3: run a different instance of rsyncd if the connection comes
# from network 172.20.0.0/24, but regular for others:
# rsyncd : 172.20.0.0/255.255.255.0 : twist /usr/local/sbin/my_rsyncd-script
# rsyncd : ALL : ALLOW
#

sshd: 192.168.2.0/24
proftp: 192.168.2.0/24
upsd: 192.168.2.0/24
nfsd: 192.168.2.0/24


Auf dem Client habe ich die beide in der fstab eingebunden:


192.168.2.2:/mnt/local/fileshares/public /mnt/remote/SoltauSuseServer_Public nfs defaults,bg,rw,auto,user,soft 0 0
192.168.2.2:/mnt/local/fileshares/private/martin /home/martin/Downloads/special nfs defaults,bg,rw,auto,soft,user 0 0
/dev/disk/by-id/scsi-SATA_WDC_WD20EARS-00_WD-WMAZA1848866-part1 /mnt/local/extern1 ext4 defaults,rw,noauto,user 0 0


Der Public-Mount geht ganz problemlos.
Beim Private-Mount erhalte ich:

mount.nfs: access denied by server while mounting 192.168.2.2:/mnt/local/fileshares/private/martin

Woran kann das denn noch liegen?

Danke und Gruß,
Martin

kreol
04.04.11, 21:17
Prüf mal die Rechte am Verzeichnis 192.168.2.2:/mnt/local/fileshares/private/martin.

Stimmen UID/GID bei Server und Client überein?

Kreol

smartysmart34
04.04.11, 21:27
Owner auf dem Server: martin:users (1000:100)
mountender User auf der Workstation: martin, mitglied in users (1000:100)

Soweit deckungsgleich...?!?

DrunkenFreak
04.04.11, 21:35
Das sieht weniger nach einem Berechtigungsproblem auf Dateisystemebene aus. Ich tippe hier auf fehlende Dienste in /etc/hosts.allow. Portmap z.B. fehlt.

Siehe auch hier (http://tldp.org/HOWTO/NFS-HOWTO/server.html#CONFIG)

smartysmart34
04.04.11, 21:38
Aber müsste dann nicht auch der public-mount fehlschlagen?

Was unterscheidet dnen di ebeiden so, dass der eine geht und der andere nicht?

Tux-Junkie
04.04.11, 21:44
Ich sehe Unterschiedliche IP's in der export & fstab.

DrunkenFreak
04.04.11, 21:44
Das hab ich wohl überlesen.

Wenn ich das richtig sehe, ist da kein Unterschied zwischen den beiden Exports, bis auf den Pfad. Was sagt denn der Server zu der ganzen Geschichte? Irgendwelche Logs?

Tux-Junkie
04.04.11, 22:05
Sehe ich das richtig, dass in einem freigegebenen Verzeichnis ein weiteres freigegeben wird?
Hab mal gelesen das sei nich zu empfehlen oder mache keinen Sinn. Kann bei nfs Ärger machen....so in etwa der Wortlaut.

Als Laie würd ich sagen: Denn Untergeordneten share aus der exports raus und die fstab lassen wie sie ist.

smartysmart34
04.04.11, 22:11
Ich sehe Unterschiedliche IP's in der export & fstab.

Das hoffe ich doch. Die exports liegt auf dem Server und berechtigt das Subnetz, die fstab liegt auf dem Client. Oder habe ich DIch falsch verstanden?

DrunkenFreak
04.04.11, 22:12
Das hoffe ich doch. Die exports liegt auf dem Server und berechtigt das Subnetz, die fstab liegt auf dem Client. Oder habe ich DIch falsch verstanden?

Das ist richtig so.

smartysmart34
04.04.11, 22:13
Sehe ich das richtig, dass in einem freigegebenen Verzeichnis ein weiteres freigegeben wird?


Nein. Das sind zwei nebeneinander stehende VErzsichnisse
/mnt/local/fileshares/public
/mnt/local/fileshares/private/martin

Also nicht geschachtelt.

Unter Suse 11.2 hat das auch so geklappt. Ich muss da scheinbar noch irgendwas anderes gemacht haben, aber die Verzeichnisse und die exports waren identisch

smartysmart34
04.04.11, 22:15
Auf dem Server sehe ich leider nix in den Logs.

Damals unter Debian gab es ja den Syslog und den auth-log. Hier unter Suse wüsste ich nur, in warn, messages oder boot zu schauen. Alternativ dmesg. Da sehe ich aber nix. Welcher Log wäre denn angebracht?

smartysmart34
05.04.11, 08:12
Oh mann!

Also, es reicht ganz offensichtlich nicht, nur auf dem tatsächlich freigegebenen Fileshare berechtigt zu sein (in meinem Fall .../martin), sondern auf dem ganzen Pfad bis dahin, zumindest eins drüber. Ich war auf /private nicht berechtigt.

Manchmal.... sieht man den Wald vor Bäumen nicht.

Danke und Gruß,
Martin