benötige Hilfe beim Mounten von NFS-Shares

Hallo hjg ,
willkommen im Forum!

Ich habe lange "probiert", bis ich meine QNAP dazu gebracht habe, die Verbingung zuzulassen, damit ich raspiBackup mit rsync verwenden kann.
Ich habe in meiner fstab folgenden Eintrag, der mit mount -a und auch beim Systemstart funktioniert:

192.168.168.9:/Backup    /mnt/Link2-NFS    nfs    nofail,rw,_netdev

In älteren OS (z.B. Bullseye) musste ich bei den Optionen noch ,vers=3 hinzufügen.
Aber auch in der QNAP brauchst du für das Verzeichnis eine NFS Freigabe!

Viel Erfolg!
Christian

Quote

sehe die enthaltenen Dateien darauf, kann diese aber nicht öffnen

Hast Du Schreibberechtigung für /mnt/QNAS1/Public?
Ich habe für meinen MountPoint alle Berechtigungen für alle freigegeben sudo chmod 777 /mnt/QNAS1/Public

Wie sind, nach dem mounten, die Berechtigungen der Dateien: ls -l /mnt/QNAS1/Public 

Mit automount habe ich nur schlechte Erfahrungen.
Ich verwende einen Eintrag in /etc/fstab:
192.168.10.200:/Public /mnt/QNAS1/Public nfs noauto,users,soft 0  0

"noauto" verhindert Probleme beim Start des Rechners, wenn die nfs-Share nicht online ist und "users" erlaubt das Mounten für normale Benutzer (ohne sudo).
"soft" ist gefährlich! What are the differences between hard mount and soft mount 

im Dolhpin sehe ich damit die Freigabe unter "Orte". Bei einem Doppel-Klick darauf wird sie gemountet und auch gleich geöffnet.

Da ich meine PIs "Headless" betreibe, kann ich Dir nicht sagen wie das mit dem Dateiexplorer am Pi funktioniert. Wenn Du sicher bist, dass die Share beim Start des PIs immer verfügbar ist, lass einfach "noauto" weg.

Quote from Gerhard-Vienna

"noauto" verhindert Probleme beim Start des Rechners, wenn die nfs-Share nicht online ist

Nein. noauto macht genau das was der Name sagt: Es wird nicht automatisch gemountet.

nofail wäre die Option für das was Du beschrieben hast.

Quote from hyle

Nein. noauto macht genau das was der Name sagt: Es wird nicht automatisch gemountet.

Na ja, wenn nicht automatisch gemountet wird, gibt es auch kein (boot) fail wegen Nichterreichbarkeit.

Danke für die Klarstellung! Für den Fall, dass die Share immer bereit ist (sein sollte) ist "nofail" die bessere Lösung!

Warum ich "noauto" verwende: Ich mounte NFS-Shares nur "bei Bedarf".

Meine NAS ist überhaupt standardmäßig abgeschaltet und wird nur bei einem Zugriff (wenn sie ein Rechner mounten möchte) hochgefahren.

Mir dem Eintrag in der fstab bekomme ich sie im Dolphin als "Ort" angezeigt und sie kann von jedem User per Doppelklick gemountet und per Rechts-Klick wieder ausgehängt werden.

Ich mounte ebenfalls Shares von einem QNAP am Raspi, ich bin aber nach diesem Tutorial verfahren und habe entsprechende mount-units.

Das Tutorial beschreibt zwar einen Samba-mount, aber das funktioniert mit NFS genau so.

Gruss

Eine Mount Unit würde ich ebenfalls verwenden, wenn das ein System ohne Desktop ist. Mit Desktop ginge das ganze auf einem aktuellen Raspberry Pi OS etwas einfacher mit nm-online (und ggf. helper-Skript).

Jetzt das ABER: Das wäre erst der zweite Schritt. Vorher zu muss der Zugriff auf die manuell gemounteten Dateien erst funktionieren, denn das ist ja im Moment das Problem von hjg , was zu lösen wäre.

//Edit

hjg Ich habe zwar weder ein NAS noch einen NFS-Server im Netzwerk, aber fangen wir mal an mit: Was ist die Ausgabe von

ls -la /mnt/QNAS1/Public

? Vielleicht kann damit ja schon jemand hier etwas anfangen.

Ich habe ein Script bei mir im Repo welches checkt ob ein System online ist und dann raspiBackup aufruft. Das kann man auch nehmen um dann zu mounten. https://github.com/framps/raspiBa…upNfsWrapper.sh

Wie geschrieben hilft das jetzt nicht weiter, bzw. wäre das der zweite Schritt vor dem Ersten.

Na kommt schon! Der Client bekommt maximal die Rechte, die am NFS-Server gestattet / freigegeben sind, also entweder fehlen Anpassungen der Freigaben am NAS oder / und der Mountbefehl passt noch nicht ganz.

Quote from hyle

Wie geschrieben hilft das jetzt nicht weiter, bzw. wäre das der zweite Schritt vor dem Ersten.

Klar, aber ist vielleicht schön schon zu wissen dass es für Schritt 2 ein Template gibt

Quote from hjg

ich habe mit der Zeit einige der hier vorgeschlagenen Wege ausprobiert, leider alles ohne Erfolg.

Du hast auf der QNAP für jedes freigegebene Verzeichnis eine Zeile in der /etc/export (oder wie auch immer das jetzt bei systemd heißt)?

Denn so wie beim Samba die Verzeichnisse freigegeben werden müssen, müssen sie auch bei NFS freigegebenen. ein laufender NFS-Server gibt nichts frei, wen ihm das nicht gesagt wird.

Diese Freigaben kann man auf ein Ziel-System, ein Ziel-Netz oder Alle-Welt freigeben.

Auf einem QNAP NAS (nicht QNAS ) geht der Export am besten über die grafische Oberfläche.

Aber das scheint ja ok, denn der manuelle mount geht laut Post #1.

Nur das der Share nicht automatisch gemountet wird, wenn der Pi startet.

Leider schreibt der TE nur

Quote from hjg

Ich habe mit der Zeit einige der hier vorgeschlagenen Wege ausprobiert, leider alles ohne Erfolg.

Aber nicht, welche Wege das waren und welche Fehlermeldungen kamen.

Das es auf verschiedenen Wegen funktioniert wurde hier nun auch mehrfach gesagt, also daher bitte genauere Angaben liefern:

Welche Wege, welche Fehlermeldungen? Nur so kommen wir weiter.

Gruss

Quote from FSC830

denn der manuelle mount geht laut Post #1

Nicht so richtig, denn in #1 steht:

Quote from hjg

manuell kann ich die Freigabe mounten, sehe die enthaltenen Dateien darauf, kann diese aber nicht öffnen

Quote from hjg

Code

ls -la /mnt/QNAS1/Public

bringt folgende Ausgabe

insgesamt 4
drwxr-xr-x 2 root root 0 5. Jan 15:19 .
drwxr-xr-x 4 root root 4096 5. Jan 15:42 ..

Das ist offensichtlich OHNE dass du die NFS-Share mountest. Ich würde hier sicherheitshalber für alle Berechtigungen freigeben, obwohl es eigentlich auch so gehen sollte:

sudo chmod 777 /mnt
sudo chmod 777 /mnt/QNAS1
sudo chmod 777 /mnt/QNAs1/Public

ABER aufschlußreicher ist die Ausgabe von ls -la /mnt/QNAS1/Public wenn Du die Share, wie in Deinem ersten Posting geschrieben hast, manuell mountest!

Was ist die Ausgabe von

getfacl /mnt/QNAS1/Public/qts5.0.x-ug-02-de-de.zip

?

Hi hjg,
also ich vermute immer noch einen Konfigurationsfehler auf der QNAP.

Kannst du dich per ssh an der QNAP anmelden?

Dann dort den Befehl cat /etc/exports eingeben. Es müsste etwas in der Art zu sehen sein:

[~] # cat /etc/exports
"/share/CACHEDEV1_DATA/Link2/Backup/raspi-backup-neu" 192.168.168.0/24(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=......)
"/share/NFSv=4" *(no_subtree_check,no_root_squash,insecure,fsid=0)
"/share/NFSv=4/Backup" 192.168.168.0/24(sec=sys,rw,async,wdelay,insecure,nohide,no_subtree_check,no_root_squash,fsid=......)
"/share/CACHEDEV1_DATA/Link2" 192.168.168.0/24(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=......)
"/share/NFSv=4/Link2" 192.168.168.0/24(sec=sys,rw,async,wdelay,insecure,nohide,no_subtree_check,no_root_squash,fsid=......)
"/share/CACHEDEV1_DATA/Linkstation" 192.168.168.0/24(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=......)
"/share/NFSv=4/Linkstation" 192.168.168.0/24(sec=sys,rw,async,wdelay,insecure,nohide,no_subtree_check,no_root_squash,fsid=......)
[~] #

Wichtig ist, dass da bei jedem Eintrag no_root_squash steht.
Sonst geht es nicht!

Gruß
Christian