NFS-Server Addon

also ich habs ehrlich gelesen.
einzige was ich finden konnte war:
"only effective on SINGLE HOST exports"
meinst du das?

wenn ja, bin ich nicht sicher, was ein single host export genau ist, denn wenns drum geht nur eine IP, die des einen erlaubten clients einzugeben, dass funktioniert das nicht. und host ist ja eigentlich die 7170. wie stelle ich das aber ein. oder müsste ich dann hosts.allow einstellen?
 
Zuletzt bearbeitet:
hmmm. könntest du mir dann kurz helfen das einzurichten?

nehme an, das ginge dann über die hosts.allow und hosts.deny, richtig?

aber bin nicht sicher, wie ich das genau einstelle.
einfach nur:
service:192.x.x.1
portmap:192.x.x.1
lockd:192.x.x.1
mountd:192.x.x.1
mit 192.x.x.1 der ip der fritzbox?
 
Nun, wir reden hier von der Datei exports und der dazugehörenden Beschreibung. Ich habe darin nichts von hosts.allow oder hosts.deny gelesen.

Außerdem:
mit 192.x.x.1 der ip der fritzbox?
Das soll was bewirken? Daß nur noch die Box selbst auf sich zugreifen darf?

exports(5) schrieb:
NFS clients may be specified in a number of ways:

single host
This is the most common format. You may specify a host either by an abbreviated name recognized be the resolver, the fully qualified domain name, or an IP address.

...

The nohide option is currently only effective on single host exports. It does not work reliably with netgroup, subnet, or wildcard exports.
 
ich hab vermutlich nen denkfehler, aber der host ist doch die fritzbox. sprich, ich dachte hosts.allow würde letztlich bestimmen, auf welche adresse der fritzbox zugegriffen werden kann, i.e. nur lokal auf die lokale ip oder auch via internet auf die 72.x.y.z

aber war wohl ein denkfehler.

aber ja, steht ja am anfang, was die unter single host verstehen.
also müsste ich doch explizit die adresse des client eingeben.
sprich
Code:
/var/media/ftp *(rw,anonuid=0,anongid=0,async,fsid=0,no_subtree_check,nohide)
wird zu
Code:
/var/media/ftp <IP-Client>(rw,anonuid=0,anongid=0,async,fsid=0,no_subtree_check,nohide)

aber das hatte ich probiert und da bekam ich auch nix angezeigt.
war zwar in einer VM und die VM hat ne andere IP als der rechner selbst, aber mit der IP der VM konnte ich nicht connecten und mit der IP des rechners konnte ich, aber konnte die subdirs nicht sehen.

also nehme ich an, dass es nicht funktioniert hat aber die ip gestimmt hat.
 
Zuletzt bearbeitet:
ist es irgendwie möglich zu prüfen, ob nohide implementiert ist oder nicht?

laut http://docs.fedoraproject.org/selin...ined_Services-NFS-Configuration_Examples.html müsste es nämlich stimmen, dass ein single host einfach die angabe nur einer client-ip ist.

Edit the /etc/exports file and add the following line to the top of the file:
Code:
/myshare 	192.168.1.100(rw)
This entry shows the full path on the server to the shared folder /myshare, the host or network range that nfs-srv will share to (in this case the IP address of a single host, nfs-client at 192.168.1.100), and finally the share permissions. Read and write permissions are given here, as indicated by (rw).
 
ich dachte hosts.allow würde letztlich bestimmen, auf welche adresse der fritzbox zugegriffen werden kann, i.e. nur lokal auf die lokale ip oder auch via internet auf die 72.x.y.z
Für so etwas ist ein Firewall da.

Mit Host ist ein Rechner gemeint, was nicht unbedingt etwas mit Client oder Server zu tun haben muß. Speziell in der Anfangszeit gab es fast nur Multiuser-Systeme, die sowieso häufig die Rollen als Server und als Client gleichzeitig hatten. Heutzutage geht das auch noch, ist aber nicht mehr so häufig.

war zwar in einer VM und die VM hat ne andere IP als der rechner selbst, aber mit der IP der VM konnte ich nicht connecten und mit der IP des rechners konnte ich, aber konnte die subdirs nicht sehen.
Hat Deine VM etwas eine Netzwerkverbindung über NAT? Jedenfalls, wenn der Mount erfolgreich ist, dann war auch die Adresse passend. Ansonsten wäre der Mount wegen fehlender Berechtigung abgewiesen worden.

ist es irgendwie möglich zu prüfen, ob nohide implementiert ist oder nicht
Das tust Du doch gerade, oder? Wie bereits geschrieben, habe ich nohide noch nie verwendet, und der Kernel der 7170 stammt von 2005. Vielleicht ist es auch ein Problem mit dem NFS-Client, oder das im Manual erwähnte Problem, daß es generell nicht funktionieren muß, weil der NFS-Standard nicht dafür ausgelegt ist.

Ansonsten könnte es auch sein, daß crossmnt die Option ist, nach der Du suchst.
 
ich meinte eine andere prüfmethode als trial-and-error ;)

also, nohide scheint jedenfalls entweder nicht implementiert, oder die syntax ist falsch oder der kernel unterstützt es nicht oder der client unterstützt es nicht.

ich hätte gedacht, dass der server einen fehler meldet, wenn eine option eingetragen ist, die nicht bekannt ist.
sprich wenn der kernel nohide nicht kennen würde, dann würde der server nicht starten.

crossmnt geht auch nicht.
wobei die erklärung irgendwie merkwürdig ist.
Thus when a child filesystem "B" is mounted on a parent "A", setting crossmnt on "A" has the same effect as setting "nohide" on B.
und bei nohide
Setting the nohide option on a filesystem causes it not to be hidden, and an appropriately authorised client will be able to move from the parent to that filesystem without noticing the change.

sprich bei beiden erlaubt die option, dass man vom parent-dir zum sub-dir springt. und bei beiden setzt man doch die option letztlich bei der freigabe des parents.

sprich bei beiden muss ich die freigabe /var/media/ftp erzeugen, damit ich auf alle usb sticks an der kathi zugreifen kann.

argh.
manchmal ist ein linux system schon kompliziert :D

also, letztlich versuche ich /var/media/ftp freizugeben, damit alle angeschlossenen usb sticks per nfs erreichbar sind. dabei sind die sticks entweder fat32 oder die hdds ntfs. beides kann der kernel ja mounten.
 
Versuch mal zur Abwechslung um eine Vermutung zu verifizieren, ein Image mit ext2(oder ext3)-modulen, und nimm einen Stcik/Platte/Partition, die damit formatiert ist und versuche eben diese freizugeben. Wenn das klappt, hast du dein Problem eingegrenzt.
 
Wie bereits geschrieben ist NFS dazu gedacht, einzelne Dateisysteme zu mounten. Die Optionen nohide und crossmnt sind Erweiterungen, die ursprünglich nicht vorgesehen waren. Bei mir hat es funktioniert, wenn ich auch eine Mount-Erlaubnis auf das untergeordnete Dateisystem in /etc/exports eingetragen habe, und auf dem übergeordneten Verzeichnis die Option crossmnt gesetzt ist. Nach dem Mounten muß aber die /etc/exports neu eingelesen werden ("exportfs -r"). Und der Client darf nicht das leere verzeichnis vor dem Mounten zwischengespeichert haben. Das Ganze habe ich zwischen zwei normalen, relativ aktuellen Linux-Systemen gemacht.

Nebenbei weiß ich nicht, ob Windows einen gleichzeitigen Zugriff auf mehrere Dateisysteme erlauben würde. Der übliche Weg unter Windows wäre, für jedes Speichermedium eine eigene Freigabe zu erstellen. Und eine eigene Freigabe für jedes Dateisystem würde auch unter Linux funktionieren.
 
zugriff würde ja von linux erfolgen, nicht windows.

musstest du nur eines der unterverzeichnisse freigeben oder alle?

sprich, ich gebe "/var/media/ftp" in dem wiederum uStor01 und uStor11 liegen. um in beide unterordner zu kommen, müsste ich dann beide unterordner freigeben oder nur einen.
sozusagen einmal ext2 und einmal fat32? sprich nicht die ordner, sondern die dateisysteme müssen je einmal als export vorliegen?

p.s.: mit ext2 auf dem stick teste ich mal schnell


EDIT:
also, stick mit ext2 formatiert. bringt auch nix. kein zugriff auf die unterverzeichnisse.
 
Zuletzt bearbeitet:
Wenn du schon dabei bist: Verifizier doch mal bitte noch "schnell", ob du den Stick direkt freigeben kannst mit FAT32 bzw. mit ext2/3 funktioniert es ja hier.

Edit: Kannst du auch lassen, ich habs grad mal verifiziert.

Edit2: Mount von /dev/sda1 und sda2 (ext2 und vfat) ok
Code:
Sep 19 21:51:31 fritz daemon.notice mountd[2345]: authenticated mount request from 192.168.11.100:756 for /var/media/ftp/uStor01 (/var/media/ftp/uStor01)
Sep 19 21:52:23 fritz daemon.notice mountd[2345]: authenticated mount request from 192.168.11.100:818 for /var/media/ftp/uStor02 (/var/media/ftp/uStor02)
Sep 19 21:54:48 fritz daemon.notice mountd[2345]: authenticated unmount request from 192.168.11.100:629 for /var/media/ftp/uStor01 (/var/media/ftp/uStor01)
Sep 19 21:54:49 fritz daemon.notice mountd[2345]: authenticated unmount request from 192.168.11.100:629 for /var/media/ftp/uStor02 (/var/media/ftp/uStor02)
Sep 19 21:58:11 fritz daemon.notice mountd[4455]: authenticated mount request from 192.168.11.100:670 for /var/media/ftp (/var/media/ftp)
Sep 19 21:58:11 fritz daemon.warn mountd[4455]: getfh failed: Operation not permitted
Ich kann bei mir mit meiner 7240 gar nichts vergleichbares freigeben.

Edit3:
Und es geht nicht weil... *trommelwirbel*
Code:
/var/mod/root # exportfs -r
exportfs: Warning: /var/media/ftp does not support NFS export.
/var/mod/root #

Somit wäre das - zumindest in meiner Konstellation - nicht möglich auf diese Art und Weise.

Edit4:

Kein Wunder, denn nfsv2&3 (die nutzen wir hier) kann kein tmpfs und vergleichbares freigeben. Da /var ja wohl als tmpfs angelegt wird, ist das somit echt nicht machbar.
Local file systems that are known not to work with the Linux NFS server are: procfs, sysfs, tmpfs (and friends).
Dies feine Stück Text findet sich in den nfs-faq auf SF.
 
Zuletzt bearbeitet:
ah!!!!

das mit dem direkten mounten hatte ich ja ein paar posts zuvor schon getestet.
dann wär jetzt die frage, ob man einen symlink auf /var/media/ftp setzen könnte. oder wär das dann auch ein tmpfs?
falls das geht, wohin kann man denn einen solchen symlink dauerhaft anlegen damit es funktioniert (in welchen ordner im flash)?
 
zugriff würde ja von linux erfolgen, nicht windows.
Das bezog sich auf Deine Bemerkung "manchmal ist ein linux system schon kompliziert". Unter Windows würdest Du vermutlich gar nicht auf die Idee kommen, es zu versuchen.

musstest du nur eines der unterverzeichnisse freigeben oder alle?

sprich, ich gebe "/var/media/ftp" in dem wiederum uStor01 und uStor11 liegen. um in beide unterordner zu kommen, müsste ich dann beide unterordner freigeben oder nur einen.
sozusagen einmal ext2 und einmal fat32? sprich nicht die ordner, sondern die dateisysteme müssen je einmal als export vorliegen?
Ich dachte, ich hätte schon geschrieben, daß ich es auf PC-Linux Systemen versucht habe. Diese haben keine Verzeichnisse uStor01 und uStor11.

Außerdem, wenn man etwas darüber nachdenkt, wieso sollte der Zugriff auf ein Verzeichnis uStor01 funktionieren, weil man ein Verzeichnis uStor11 freigegeben hat?
Es müssen nicht Verzeichnisse freigegeben werden, sondern Dateisysteme. Damit sind aber nicht Typen von Dateisystemen gemeint, also nicht FAT/NTFS/EXT2, sondern das Dateisystem von ersten USB-Speicher und das vom zweiten USB-Speicher.

Code:
/var/mod/root # exportfs -r
exportfs: Warning: /var/media/ftp does not support NFS export.

Aber bei officiallyme scheint das zu funktionieren.
 
Außerdem, wenn man etwas darüber nachdenkt, wieso sollte der Zugriff auf ein Verzeichnis uStor01 funktionieren, weil man ein Verzeichnis uStor11 freigegeben hat?
Es müssen nicht Verzeichnisse freigegeben werden, sondern Dateisysteme. Damit sind aber nicht Typen von Dateisystemen gemeint, also nicht FAT/NTFS/EXT2, sondern das Dateisystem von ersten USB-Speicher und das vom zweiten USB-Speicher.
Da lag das missverständnis. dachte es geht um den typ (fat etc.) und somit war die frage, ob es reicht eins von jedem.
es geht also eigentlich um das dateisystem eines devices. sehr umständlich.

Aber bei officiallyme scheint das zu funktionieren.
ja. tuts auch.

Code:
/var/mod/root # exportfs -r
/var/mod/root #

hier nochmal die ausgabe von "mount". die verzeichnisse uStor01 und uStor11 habe ich NICHT freigegeben, sondern ich habe das verzeichnis /var/media/ftp freigegeben. sowohl in samba als auch nfs.
Code:
/var/mod/root # mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
dev on /dev type tmpfs (rw,nosuid)
proc on /proc type proc (rw,nodiratime,nosuid,nodev,noexec)
tmpfs on /var type tmpfs (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
/dev/mtdblock6 on /data type jffs2 (rw,noatime)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /var/media/ftp/uStor01 type vfat (rw,nodiratime,fmask=0000,dmask=0000,codepage=cp437,iocharset=is
o8859-1)
/dev/sdb1 on /var/media/ftp/uStor11 type ext2 (rw,noatime,nodiratime)
/var/mod/root #
aber weder der inhalt von der ext2 uStor11 noch vom fat32 uStor01 sind einsehbar beim freigeben von /var/media/ftp

ich trag jetzt nochmal syslogd in die rc.costum ein, damit mal dauerhaft mitgeloggt wird auch nach neustart. habs nämlich vorhin vergessen, dann schau ich mal, was er sagt, wenn sich der satreceiver verbindet.
 
Aber bei officiallyme scheint das zu funktionieren.

Interessant, denn zumindest per Default sollte das nicht gehen. ;) Aber wer weiss, was am 2.6.13er kernel noch alles anders war. Ich kann mich ehrlich nicht mehr erinnern.
 
[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
kurzes off-topic:
könnt ihr als mods mir nebenbei sagen wieso hier im p.s. "c heck" steht obwohl in wirklichkeit (im editiermodus) da "check" steht.

hatte nämlich gerade mal kurz die zeile kopiert, um es nochmal anders zu testen und erst nicht gemerkt und bekommt man natürlich nur syntax-fehler.

aber wie gesagt, off-topic, denn daran liegts nicht ;)

[Beitrag 2:]
Interessant, denn zumindest per Default sollte das nicht gehen.
wenn du sagst "per default", gibts dann ne möglichkeit dies einzuschalten? eventuell "gehts" auch nicht richtig und wird nur nicht als mount-fehler abgebrochen. wer weiss.
muss ja irgendwie möglich sein das ganze.
falls jemand die antwort auf die symlink frage weiss, wäre auch interessant.
 
wenn du sagst "per default", gibts dann ne möglichkeit dies einzuschalten?

Ich denke nicht, es sei denn der alte Kernel handled das mit den Filesystemen anders. Ich habe aktuell nur eine 72xx zum überprüfen dieser Sachen da, deswegen ist der Vergleich irgendwie mit Äpfeln und Birnen zu vergleichen.

Ich wage mich auch ganz grob zu erinnern, dass wir irgendwann da was dran gedreht hatten, aber ich keine Ahnung mehr habe weshalb und wieso. (Edit: r2110)

Symlink: Keine direkte Antwort, sondern ein "RTFM". Was steht da über Optionen die überprüfen, ob ein File in "subtree" liegt? ;) btw: Ein Symlink z.B. auf "/" geht dann auf das "/" des mountenden Rechners ;)
 
Symlink: Keine direkte Antwort, sondern ein "RTFM". Was steht da über Optionen die überprüfen, ob ein File in "subtree" liegt? ;)
Hatte die seite nach "sym", "link", "ln" durchsucht und nix gefunden. deshalb hatte ich gefragt.

das mit dem subtree verstehe ich nicht so ganz. wenn ich subtree checking abgeschaltet habe, dann ist es ihm egal, worum es sich handelt?

btw: Ein Symlink z.B. auf "/" geht dann auf das "/" des mountenden Rechners ;)
?
wenn ich einen symlink von "/var/media/ftp" nach z.b. "/var/flash/ftp" erzeuge, dann öffnet sich der ordner "/var/media/ftp" auf der fritzbox bei öffnen von "/var/flash/ftp".
der mountende rechner hat doch damit nix zu tun. :confused:
ist doch ne verknüpfung auf der 7170.
 
das mit dem subtree verstehe ich nicht so ganz. wenn ich subtree checking abgeschaltet habe, dann ist es ihm egal, worum es sich handelt?

...

ist doch ne verknüpfung auf der 7170.

Nein, es wird nur der Check ausgestellt, ob der File (oder das verlinkte File) innerhalb der freigegebenen Struktur liegt. (Bsp: Symlink nach "/" wäre nicht in der "/home"-Freigabe).

Die Verknüpfung ist auf der 7170, das stimmt. Aber wenn du im freigegebenen Filesystem einen Symlink hast, dann ist diese eben auch für den mountenden Rechner ein Symlink (Zumindest bie symlink-tauglichen Filesystemen). Beispiel wieder: "ln -s / /var/media/ftp/uStorXY/root". Folgst du diesem Symlink auf dem Clientrechner, dann landest du in der Wurzel des Clients.
Wenn du allerdings darauf hinauswolltest, ob Symlinks generell freigegeben werden: Da wird das verlinkte Verzeichnis freigegeben, nicht der Linkl selbe.r So schlau ist das Linux-System. Und es gibt dann imemr mal wieder PRobleme mit irgendwelchen Pfaden, etc. Mir fiele sonst nur noch ein, mit "mount -o bind" zu arbeiten, wie es für nfsv4-shares in "/srv" empfohlen wird bei Mischsystemen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.