Am Montag 21 Juli 2008 um 11:31:29 schrieb Tobias Crefeld:
On Mon, 21 Jul 2008 06:40:41 +0200 Marco Jäger
wrote:
Ich habe am Haupt-PC "nur" ein CDR eingebaut (also kein Brenner), dafür aber in meinem Neben-PC. Dieses würde ich gerne komplett via NFS an meinen Hauptrechner einbinden, aber das ganze klappt nur bedingt.
Ohne Dir in allen Details folgen zu können, ein paar Hinweise:
Bei NFS-Problemen sollte man immer parallel (!) eine Konsole vom nfs-Server mit "tail -F /var/log/messages" mitlaufen lassen. nfs ist eigentlich sehr auskunftsfreudig und insbesondere "permission"-Probleme kann man so viel einfacher eingrenzen.
Anmerkung : cpu2 (NFS-Server) ist immer nebenbei via ssh-Konsole "griffbereit" ;) # << kommentarzeichen für den nächsten "logbereich" - da ich am besten beide Konsolen, bzw Tätigkeiten zeitnah angebe Versuch 1: NFS-Server frisch rebootet, kein User eingeloggt, CD eingelegt cpu2:~ # tail -F /var/log/messages Jul 21 13:04:53 cpu2 kernel: eth0: no IPv6 routers present Jul 21 13:04:53 cpu2 SuSEfirewall2: batch committing... Jul 21 13:04:53 cpu2 SuSEfirewall2: Firewall rules successfully set Jul 21 13:04:53 cpu2 kernel: bootsplash: status on console 0 changed to on Jul 21 13:04:54 cpu2 kernel: ra0: no IPv6 routers present Jul 21 13:06:18 cpu2 sshd[5254]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 28636 ssh2 # cpu1.root -> manueller mount (NFS ist ohne automount eingestellt) cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram mount: cpu2.linuxcobra.lan:/media/cdram failed, reason given by server: Permission denied # tail auf ssh-konsole cpu2: Jul 21 13:06:18 cpu2 sshd[5254]: Accepted keyboard-interactive/pam for root from 192.168.2.21 port 28636 ssh2 Jul 21 13:08:13 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:900 for /media/cdram (/media/cdram) # mehr Infos kamen nicht hmhh also auskunftsfreudig ? *hust* laut meinem "Verständnis" sagt auf cpu2 der rpc.mountd das die Anfrage ok geht - oder seh ich das falsch??? -warum bekommt also cpu1.root die verweigerung ? *kopfkratz* Versuch 2: auf CPU2 hab ich mich als User unter KDE eingeloggt, cd raus und wieder rein (KDE-Erkennung für CD-Medien staret (das nette fenster wo gefragt wird was man mit der CD machen will)), aber nichts !!! ausgewählt # cpu1.root -> manueller mount cpu1:~ # mount cpu2.linuxcobra.lan:/media/cdram cpu1:~ # # tail auf ssh-konsole cpu2: Jul 21 13:21:37 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:983 for /media/cdram (/media/cdram) Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: SYMLINKS:: disk/by-id/ata-HL-DT-ST_CDRAM_GSA-H10N_2AFEB00ED410 disk/by-path/pci-0000:00:07.1-ide-1:0 cdram cdrom cd Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: MOUNT_POINT:: /media/cdram Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: MOUNTPOINT:: /media/cdram Jul 21 13:21:46 cpu2 hal-subfs-mount[5521]: Collected mount options and Called(0) /bin/mount -t subfs -o fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=iso8859-15 /dev/hdc "/media/cdram" Jul 21 13:21:46 cpu2 kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Jul 21 13:21:46 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'mount' Jul 21 13:21:46 cpu2 kernel: ISO 9660 Extensions: IEEE_P1282 Jul 21 13:21:49 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'umount' Jul 21 13:21:49 cpu2 kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Jul 21 13:21:49 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'mount' Jul 21 13:21:49 cpu2 kernel: ISO 9660 Extensions: IEEE_P1282 Jul 21 13:21:52 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'umount' # Inhaltsverzeichnis der CD ist kurzzeitig lesbar - wenn man via konqueror dort einen reload macht / eine Datei öffnet : Datei/Verzeichnis nicht gefunden Manchmal dauert die Zeitspanne bis die CD "zumacht" etwa 2-3 min , in dieser zeit kann man dann Dateien von der CD abrufen - sobald ma naber eine Pause länger wie 5 Min hat -> 100% stille danach kommt, sebst wenn man die CD wechselt, nur eine verweigerung beim erneuten mount # cpu1.root cpu1:~ # umount cpu2.linuxcobra.lan:/media/dvdram cpu1:~ # mount cpu2.linuxcobra.lan:/media/dvdram mount: cpu2.linuxcobra.lan:/media/dvdram failed, reason given by server: Permission denied cpu1:~ # # tail auf ssh-konsole cpu2: Jul 21 13:21:52 cpu2 udevd[1927]: get_netlink_msg: no ACTION in payload found, skip event 'umount' Jul 21 13:25:45 cpu2 rpc.mountd: authenticated unmount request from cpu1.linuxcobra.lan:607 for /media/dvdram (/media/dvdram) Jul 21 13:25:47 cpu2 rpc.mountd: authenticated mount request from cpu1.linuxcobra.lan:611 for /media/dvdram (/media/dvdram) Also das einzige was richtung "Auskunft" gehen könnte, wäre der Teil wenn der NFS-Server die CD exportiert hat und das LW kommt zur Ruhe - beim großen Rest... hmhh nichts an weiterführenden Infos :((
Um die Unterschiede zwischen "mount an der Konsole" und "mounten per Desktop" festzustellen, solltest Du nach dem jeweiligen mounting an der Konsole "mount" aufrufen und die jeweiligen Parameter vergleichen. Es hängt letztlich davon ab, ob und was in der /etc/fstab drinsteht, aber bei mir sieht der Unterschied wie folgt aus:
mount per KDE: /dev/sr1 on /media/IX04 type iso9660 (ro,nosuid,nodev,noatime,uid=500,utf8)
"mount /dev/sr1 /media/cd" ohne fstab-Eintrag: /dev/sr1 on /media/cd type iso9660 (ro)
Daraus kann man schon leicht erkennen, dass die Rechte auf das Laufwerk von der Mount-Methode abhängen. Nachdem die meisten nfs-Installationen mit root_squash arbeiten, wird z.B. ein CD-mount, der root gehört, mitunter nicht per nfs verwendbar sein. Oder die UIDs sind inkonsistent. Bei einem Server würde ich das Mounten per Desktop deaktivieren und stattdessen "automount" benutzen. Alternativ befasst man sich mit der Konfiguration von hal. Außerdem sollte man den nfs-Export davon abhängig machen, dass der Mount erfolgreich war.
BTW: Eine Ursache für erfolglose umount-Versuche kann KDE sein. Das hat gelegentlich die Eigenart, ein Fenster zu schließen, ohne den Lock aufs Verzeichnis freizugeben. Man findet dann meist irgendwelche kio-Prozesse im "ps axf", deren gewaltsames Ende auch den Lock wieder freigibt.
Was bei mir nie wirklich stabil funktionierte: Wenn am "Server" parallel zum nfs-Service mit Schreibwerkzeugen gearbeitet wird, also cdrecord, k3b, usw..
-- Gruß, Tobias.
Per KDE mounte ich nix freiwillig - immo eher Zwangsweise, da das exportieren vom Server nicht 100%ig klappt - aber im "Normalfall" ist der Server ohne Userlogin (höchstens via SSH-Konsole) aber alle NFS -Verzeichnisse die vom Server (cpu2) exportiert werden (sollen), muss ich auf cpu1 manuell mounten/umounten Einträge zu dem ganzen in der jeweilligen fstab, Original Yast-Einträge: cpu2: /dev/cdram /media/cdram subfs noauto,fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 cpu1: cpu2.linuxcobra.lan:/media/cdram /home/jmarco/HD/cpu2:cdr nfs defaults 0 0 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org