Hi,

Kurzfassung: Ich kann keine NFS-Mount auf das eigentliche Verzeichnis innerhalb einer freigegebenen NFS Ressource erstellen. Das ergibt nur einen Timeout. Ein Mount nur auf die Ressource funktioniert - ist aber sehr unschön.

Langfassung:

Ich habe gerade die neue VU+ ausgepackt, VTi draufgespielt. Ferngucken läuft soweit. Im Netz hängt sie auch. Nun wollte ich mal was aufnehmen. Die Solo2 hat keine eigene Festplatte, sondern soll sich des Servers hier bedienen. Eine NFS-Freigabe zu diesem Zweck ist im LAN vorhanden: /mnt/zfs/netstore
Genutzt werden soll dort das Verzeichnis /mnt/zfs/netstore/Media/Video_Vu
Problem: /mnt/zfs/netstore lässt sich mounten. Das Schöne an NFS ist ja aber, dass man direkt das passende Verzeichnis mounten kann. Das aber geht leider nicht. Weder /mnt/zfs/netstore/Media noch /mnt/zfs/netstore/Media/Video_vu lassen sich mounten.

1. Versuch über die Menüstruktur mit der Fernbedienung entsprechend Freigabe-Manager lt. Wiki führt zu einem roten Kreuz.
2. Versuch via SSH führt zu einem timeout:

Und das war's. Der Cursor blinkt und blinkt, nichts passiert mehr.

Falls es von Interesse ist: Der Server läuft unter Ubuntu 14.04.4 Server. Der Mount-Befehl (mit "Deep Link") funktioniert von anderen Linux-Rechnern (Ubuntu, OpenELEC) problemlos. Und auch lt. Anleitung im Wiki soll ja der Mount direkt auf das richtige Verzeichnis gehen. Was mache ich falsch?

Ich habe bei der Suche was von auto.network gefunden, samt Anleitung. Aber die Anleitung setzt einen grundsätzlich funktionierenden mount voraus. Außerdem ist mir nicht klar, was der Eintrag "HD Replacement" im Freigabe-Manager faktisch macht und wie ich das beim Mounten via auto.network abbilden soll (softlink von /media/hdd/movies auf /media/net/<Freigabe>?), so dass ich das weitere Herumbasteln damit erstmal sein gelassen habe.

Es dankt für hoffentlich hilfreiche Hinweise
der Tee Pfau

Danke, mein Ergebnis:

Inhalt auto.network:


Rechte:
automounts.xml ist leer:
Mount klappt nicht:
(Das Verzeichnis "server" hat er automatisch angelegt, ich habe da nichts gemacht.)

Edith sagt: Wenn ich den Eintrag ändere auf "Link zur Ressource" anstatt "Deep Link" (s. Problembeschreibung oben), funktioniert es auch auf diesem Weg:

Vorgehensweise exakt wie oben (kein Verzeichnis manuell angelegt etc.).

shadowrider schrieb:

sicher, das das mount-Ziel korrekt ist?...168.174:/mnt/zfs...
das sieht mir doch bereits wie ein vorhandener mount aus?
üblich sind ja oft 168/174:/volume1/verzeichnis usw.

Ja, das mount-Ziel ist korrekt. Das ist ein 8-Disk+ZIL-ZFS-Raid. Das muss man - wie jedes RAID - erstmal irgendwohin mounten, bevor man es dann im Netzwerk verteilen kann. Daher ist /mnt/zfs/netstore der lokale Ort, von dem aus der Server das dann verteilt.

Rechte sind dieselben, denn /mnt/zfs/netstore ist das Share, Media/Video_Vu ein Verzeichnis in diesem Share. Und /mnt/zfs/netstore kann ich ja auf der VU mounten. Bei fehldenden Rechten bekomme ich auch ein access denied als Fehler (habe noch mehr Shares, die nicht so großzügig verteilt werden, damit lässt sich das gut testen), kein Timeout.


Zum Thema Leerzeile: Ja, ist drin. Außerdem ist der nicht funktionierende Eintrag ("Deep Link") in auto.network ist der erste, der zweite (letzte, testweise angelegte) funktioniert:

shadowrider schrieb:

grad zwei Dinge gefunden:
kann es sein, das es für netstore

-fstype=nfs,rw,soft,nolock,udp,rsize=8192,wsize=8192 192.168.2.3:/public
heißen sollte?zudem gab es zumindest wohl erhebliche probleme mit diesem teil als solches, habe deartiges in bezug auf andere Boxen grad gelesen

Zu spät gesehen... Teste ich nachher mal.

Ich wüsste nicht, wie es an den Rechten liegen sollte, wo die sich doch nur pro Share setzen lassen (und das ist hier ja derselbe Share). Außerdem führen Probleme in den Rechten nicht zu einem Timeout, sondern zu access denied Fehlern - jedenfalls bei meinen Tests...

Aber ok, dann finde ich mich damit ab, dass der direkte Mount des passenden Verzeichnisses nicht funktioniert und arbeite mit SymLink, oder ich ändere in der Config einfach das Aufnahme-Verzeichnis.

Danke!

tonskidutch schrieb:

Moin,ich nimm an du hast die /etc/export datei { auf dem Server } angepasst fuer die VU+?
Und die Firewall ist angepasst damit die VU+ an die Daten darf?

Das spielt sich alles hinter der Firewall ab. zfs arbeitet mit dem Standard-NFS-Server zusammen, aber nicht mit /etc/exports, sondern über eigene Attribute. Aber das passt soweit, wie showmount zeigt:
Es geht ja auch, aber halt nur via /mnt/zfs/netstore und nicht via /mnt/zfs/netstore/Media/Video_Vu (oder auch via /mnt/zfs/netstore/Media). D.h. im Gegensatz zu den anderen Linuxen, die hier so laufen, will die VU keinen Mount unterhalb des Share-Verzeichnisses akzeptieren. Versuche ich, einen der anderen nicht für 0.0./16 freigegebenen Shares zu mounten, oder versuche ich, ein nicht existierendes Verzeichnis zu mounten, bekomme ich entsprechende, aussagefähige Fehlermeldungen:
Nur der Mount eines existierenden Verzeichnisses unterhalb eines Shares, auf den die VU zugreifen darf, führt nach Minuten zu einem Timeout, sonst passiert nichts.

Ich mache es jetzt wie oben von shadowrider auch vorgeschlagen so, dass ich einfach den ganzen Share mounte. /media/hdd ist ein Link auf /media/autofs/server/Media/Video_Vu, und als Aufnahmeverzeichnis habe ich direkt /media/autofs/server/Media/Video_VU eingestellt. Das ist zwar nicht "hübsch", aber der Workaround funktioniert.

Yo, Deine Lösung macht so definitiv Sinn.

Das hat jetzt für den Thread hier kaum noch Bedeutung, aber zur Erläuterung: Live TV gucken wir hier kaum. Die VU soll in den Speicher wandern (dort, direkt am Multiswitch, ist das SAT-Signal deutlich besser als im Rest des Hauses, denn die Koax-Verkabelung hier ist (1) unter Putz und (2) Mist) und headless Aufnahmen machen, programmiert via Webif. Geschaut wird über die bestehende Infrastruktur ein Mix aus Aufnahmen, Mediathek, Amazon, etc., wenn es uns passt. Daher brauche ich nur ein definiertes Ziel, in das die VU aufnimmt.

wsxws schrieb:

ähm, ich mahce zwar immer nur cfis-mounts, aber bei mit steht die ip nach dem doppelpunkt und nicht davor und vor dem doppelpunkt ist nen leerzeichen

aus meiner auto.network

EPGpi -fstype=cifs,rw,user=user,password=pass ://192.168.178.4/epgdat

Ich vermute, das ist genau der Unterschied zwischen nfs und cifs, der diese unterschiedliche Syntax bedingt. Schließe ich zumindest mal aus folgendem spontan gefundenen Forumsbeitrag