Seite 1 von 1

Verfasst: 09.10.2004, 20:15
von stingray2
mal vorweg, ich weiss jetzt warum es auch "nightmare filesystem" genannt wird. dieses problem wurmt mich schon seit einigen tagen.

die zielsetzung war, meinen zwei desktops einen einfachen zugang zu einem zentralen daten- und backup-archiv via nfs zu ermöglichen, welches auf einem dritten pc liegt.
mein vorgehen bisher war folgendes. ich habe nfs-support in die entsprechenden kernel der systeme einkompiliert, nfs-utils installiert, auf dem nfs-server /etc/hosts.allow/deny mit sinnvollen minimalwerten gefüllt bzw. angelegt, /etc/exports ebenfalls mit minimalwerten (root_squash) ausgestattet und portmapper auf allen nfs-beteiligten systemen gestartet.

nachdem ich das nfs-export auf dem client-system gemountet hatte, konnte ich als root in das mountpoint-verzeichnis wechseln mir allerdings keinerlei informationen über die enthaltenen dateien anzeigen lassen (ls ging, ls -l => access denied). das sollte bei root_squash ja noch normal sein. allerdings kann ich als normaler user nicht in das verzeichnis wechseln. dies wird immer mit der meldung access denied verweigert. dies wiederum liegt mit sehr hoher warscheinlichkeit an der rechtevergabe des mountpoints die im gemounteten zustand so aussieht:

drwxr--r-- 4 root root 5944 Oct 9 15:22 foo

allerdings kann ich weder die rechte mit chmod noch die owner- und group-zugehörigkeit ändern. o_O da bekanntlich umask, uid und gid im zusammenhang mit nfs aus mir nicht so ganz ersichtlichen gründen nicht funktionieren, konnte ich auch nichts über die fstab regeln. ich vermute dahinter steckt irgendein aspekt eines mir nicht bekannten sicherheitskonzeptes. :ugly:

ich vermute stark, daß dieses problem mit dem mapping der uids und gids zusammenhängt, kann aber irgendwie keinen offensichtlichen lösungsansatz für dieses problem erkennen. das studium der manpages und einer erheblichen anzahl von howtos und tutorials im netz hat mich nur bedingt weitergebracht, da diese abhandlung immer kurz vor dem spannensten teil, dem über das uid/gid-mapping aufhören.

ich hab nebenbei aufgeschnappt, daß es möglich ist die komplette user/pw/group verwaltung per nis oder ldap abzuwickeln. angenommen ich würde diesen weg einschlagen um das nfs-uid/gid-mapping-problem geschickt zu umgehen, wäre es dann immer noch möglich einen client ohne den nis- bzw. ldap-server zu booten ohne das mir alles um die ohren fliegt? einer der clients ist nämlich ein notebook, daß in unterschiedlichen netzwerken verkehrt (home, uni).

falls sich jemand ein bisschen mit nfs & co. auskennt oder irgendwas von meinen anderen fragen beantworten kann würde ich mich sehr freuen. thx :)

edit: achso falls jemand inhalte spezieller configs einsehen will kann ich diese gerne nachreichen. ich habe die nur erstmal weggelassen um euch nicht irgendwie vorzubelasten.

edit2: achso, mir fällt gerade ein, daß alles funzt wenn ich als root mit no_root_squash in dem gemounteten export hantiere. allerdings finde ich diese lösung _extrem_ unschön. schließlich soll im idealfall nur ein normaler user ohne rootrechte auf die dateien zugreifen können.

Verfasst: 09.10.2004, 20:48
von Mithrandir
Wenn es nur wenige Rechner sind kannst du dir den NIS Kram sparen und es "von Hand" machen bei wenigen Usern. Einfach jedem User die selbe UID auf jedem Rechner geben (selbes mit GIDs).

Wegen den Rechten wäre es nen Versuch wert das NFS zu unmounten, per "sudo chmod a+x foo" allen das X-Flag zu geben, damit jeder sich ein Listing anzeigen lassen kann und dann nen neuen Mountversuch zu starten. (ka obs daran liegt und ob das was nützt)

Verfasst: 09.10.2004, 21:33
von stingray2
das dumme ist, daß die rechte des mountpoints mit dem mounten "überschrieben" werden. d.h. im nichtgemounteten zustand sind sie 755 iirc, im gemounteten dann auch einmal 744. keine ahnung womit das zusammen hängt, würde mich auch mal interessieren. :>

das mit dem von hand eintragen wäre eine überlegung wert und warscheinlich die im verhältnis zum aufwand beste lösung. allerdings bringt mir das nicht viel solange das problem mit dem wechsel der rechte des mountpoints nicht gelöst ist.

trotzdem danke schonmal für den tipp. :>

Verfasst: 09.10.2004, 21:46
von R0Y2
soweit ich mich erinnere bekommt der mountpoint beim mounten die selben rechte wie das rootdir des zu mountenden dateisystems. also solltest du imho die rechte deines nfs-exports verändern. ich habe allerdings von nfs keine ahnung, also kann es sein dass ich danebenliege.

hth

Verfasst: 09.10.2004, 21:46
von Mithrandir
Dann setz mal die Rechte auf dem Server entsprechend: also "sudo chmod a+x /my/export". Kann sein dass die daher übernommen werden.

€dith sagt: 2 Dumme ein Gedanke? :D

Verfasst: 09.10.2004, 22:08
von R0Y2
na wenn edith das sagt wirds wohl stimmen, oder? :)

Verfasst: 10.10.2004, 18:41
von stingray2
vielen dank an euch zwei, genau daran hats gelegen! habe das irgendwie übersehen, weil ich in diesem fall einen symlink exportiert hatte, dessen rechte 777 waren. das echte verzeichnis hatte aber 744 oder so. thx & excellent! :D