Auch nicht mit sudo?
Gruss
QNAP 231 mit Raspberry Pi 4 über NFS verbinden bzw. mounten
- Psychano
- Unerledigt
-
-
Dann schau noch mal auf die in #6 verlinkte Seite und führe die Schritte akribisch aus.
Ich habe das jetzt schon mehrfach eingerichtet.
Gruss
-
Guten Morgen, habe mir jetzt die Anleitung zum "IMAGE" angeschaut.In Deinem Post #4 unter Punkt 2) hast Du einen Punkt "." in dem Befehl vergessen - kann das sein?
mkfs.ext4 /media/qnap/xxxx.img ... korrekt heißt es wohl mkfs.ext4 ./media/qnap/xxxx.img
...aber selbst dann funktioniert es nicht. Kann es sein dass es etwas mit den Einstellungen auf der Qnap zu tun hat? Oder das: In der Anleitung wird erst das Image erstellt und DANACH erst gemounted. Muss das Image evt. erst DIREKT auf der QNAP erstellt werden damit es funktioniert?
Hier ein Screenshot von meiner Pi:
Mount auf den PI-Ordner der QNAP von /media/qnap auf der Pi (Ordner war bereits erstellt), in den Ordner gewechselt, ein (kleines) Testimage mit dem Namen "backuppi" erstellt...bis hierhin klappt es...
Danach kommt der Fehler mit
sudo mkfs.ext4 ./backuppi
Any ideas?
Gruß
Nachtrag:
Habe das Erstellen des Images mit anschließendem Erstellen des Dateisystems darin einfach auf der SD-Karte des pi probiert - und da funktioniert es, d.h. ich mache es korrekt
. Es hängt doch dann entweder mit den Einstellungen bzw. Berechtigungen auf der QNAP zusammen, oder mit der Reihenfolge des Mounten und Erstellen des Image-Systems auf der QNAP....oder?Code
Alles anzeigenpi@raspberrypi:/media $ sudo dd if=/dev/zero of=backuppi bs=100M count=10 10+0 Datensätze ein 10+0 Datensätze aus 1048576000 bytes (1,0 GB, 1000 MiB) copied, 27,2525 s, 38,5 MB/s pi@raspberrypi:/media $ sudo mkfs.ext4 ./backuppi mke2fs 1.44.5 (15-Dec-2018) Discarding device blocks: done Creating filesystem with 256000 4k blocks and 64000 inodes Filesystem UUID: 0186c9da-913d-479d-9753-003d251f1ac2 Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done pi@raspberrypi:/media $Nachtrag 2:
Habe mich mit Putty über SSH auf der QNAP eingeloggt und bin im Ordner /share/pi und habe mit dd if=/dev/testimage.img bs=100M count=10 ein "Image" erstellt...ist im Ordner Vorhanden.
Den Befehl mkfs.ext4 ./testimage.img nimmt er nicht. Da kommt die Fehlermeldung: ...command not found. Kennt die QNAP diesen Befehl nicht, oder wie hast Du das Image DIREKT auf der QNAP erstellt UND formatiert ins .ext4-Format? -
Ich sehe momentan den Fehler nicht, möglicherweise hängt es an der QNAP.
EInziger Unterschied den ich sehe: Du hast das Filesytem mit nfs4 gemountet, aber auch das ist kein Problem.
Nachfolgend habe ich auf die Schnelle die Befehle und die Angaben noch mal getestet. An dem "." hängt es nicht, das ist eine Pfadangabe.
Das habe ich auch dazu geschrieben.
Dennoch habe ich folgende Schritte unternommen:
1. Erstellen des Images auf einem mit nfsv3 gemounteten Share
2. Erstellen des Images auf einem mit nfsv4 gemounteten Share - vom home Verzeichnis aus
3. Erstellen des Images auf einem mit nfsv4 gemounteten Share - vom mountpount aus
4. Erstellen und mounten der unter 3 erstellten Imagedatei.
Der Fehler muss also noch irgendwo in Deiner Umgebung sein.
Gruss
Edit: Auf dem zweiten NAS (nfsv4) war das Loopdevice 0 schon belegt, daher wurde hier das Loopdevice 1 genommen.
mkfs kennt die QNAP nicht, das geht nur vom Pi aus.
Code
Alles anzeigenpi@piwx:~ $ sudo mkdir /media/NFS/test pi@piwx:~ $ sudo mount 192.168.178.20:/pitest /media/NFS/test/ pi@piwx:~ $ sudo dd if=/dev/zero of=/media/NFS/test/backup bs=100M count=10 10+0 records in 10+0 records out 1048576000 bytes (1,0 GB, 1000 MiB) copied, 18,5606 s, 56,5 MB/s pi@piwx:~ $ sudo mkfs.ext4 /media/NFS/test/backup mke2fs 1.44.5 (15-Dec-2018) Creating filesystem with 256000 4k blocks and 64000 inodes Filesystem UUID: 86bc547e-e644-4815-b168-b69e0c672918 Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: 0/8 done Writing inode tables: 0/8 done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: 0/8 done pi@piwx:~ $ ls -al /media/NFS/test total 1024016 drwxrwxrwx 3 root root 4096 Jan 16 10:33 . drwxr-xr-x 4 root root 4096 Jan 16 10:29 .. -rw-r--r-- 1 root root 1048576000 Jan 16 2021 backup drwxrwxrwx 2 root root 4096 Jan 16 10:28 @Recycle pi@piwx:~ $ sudo mount | grep -i media 192.168.178.20:/pitest on /media/NFS/test type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.178.20,mountvers=3,mountport=30000,mountproto=udp,local_lock=none,addr=192.168.178.20) pi@piwx:~ #################### TEST mit nfsv4 ##################### pi@piwx:~ $ sudo mkdir /media/NFS/testv4 $ sudo mount 192.168.178.30:/pitest -t nfs4 /media/NFS/testv4 pi@piwx:~ $ sudo dd if=/dev/zero of=/media/NFS/test/backup=100M count=10 10+0 records in 10+0 records out 1048576000 bytes (1,0 GB, 1000 MiB) copied, 19,2151 s, 54,6 MB/s pi@piwx:~ $ sudo mkfs.ext4 /media/NFS/test/backup_02 mke2fs 1.44.5 (15-Dec-2018) Creating filesystem with 256000 4k blocks and 64000 inodes Filesystem UUID: c830dbaf-9bca-4448-a720-948812fade0f Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: 0/8 done Writing inode tables: 0/8 done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: 0/8 done pi@piwx:~ $ sudo mount | grep -i media 192.168.178.30:/pitst on /media/NFS/testv4 type nfs4 (rw,relatime,vers=4.1,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.178.5,local_lock=none,addr=192.168.178.30) #################### TEST mit nfsv4 im Verzeichnis /media/NFS/testv4 ##################### pi@piwx:~ cd /media/NFS/testv4 pi@piwx:~ $ sudo dd if=/dev/zero of=./backup_02 bs=100M count=10 10+0 records in 10+0 records out 1048576000 bytes (1,0 GB, 1000 MiB) copied, 18,8573 s, 55,6 MB/s pi@piwx:~ $ sudo mkfs.ext4 ./backup_02 mke2fs 1.44.5 (15-Dec-2018) Creating filesystem with 256000 4k blocks and 64000 inodes Filesystem UUID: 24e54129-5a0d-4b99-b251-b9daf64d60c4 Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: 0/8 done Writing inode tables: 0/8 done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: 0/8 done pi@piwx:~ $ ls -al total 43008044 drwxrwxrwx 4 root root 4096 Jan 16 10:43 . drwxr-xr-x 5 root root 4096 Jan 16 10:37 .. -rw-r--r-- 1 root root 1048576000 Jan 16 10:38 backup -rw-r--r-- 1 root root 1048576000 Jan 16 2021 backup_02 -rw-r--r-- 1 root root 41943040000 Jan 6 09:50 bu_disk_01.img -rw-r--r-- 1 root root 28 Jan 6 09:01 log drwxrwxrwx 2 root root 4096 Jan 5 12:59 @Recycle drwxrwxrwx 2 root root 4096 Jan 5 12:59 .syncing_db pi@piwx:~ $ ##################### Loop device ############################## pi@piwx:~ $ pwd /media/NFS/testv4 pi@piwx:~ $ losetup NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop0 0 0 1 0 /media/NFS/Backup/bu_disk_01.img 0 512 pi@piwx:~ $ sudo losetup /dev/loop1 /media/NFS/testv4/backup_02 pi@piwx:~ $ losetup NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop1 0 0 0 0 /media/NFS/testv4/backup_02 0 512 /dev/loop0 0 0 1 0 /media/NFS/Backup/bu_disk_01.img 0 512 pi@piwx:~ $ sudo mount /dev/loop1 /mnt pi@piwx:~ $ sudo ls -al /mnt total 24 drwxr-xr-x 3 root root 4096 Jan 16 10:44 . drwxr-xr-x 18 root root 4096 Jan 5 20:17 .. drwx------ 2 root root 16384 Jan 16 10:44 lost+found pi@piwx:~ $ -
Ja, exakt gleich wie bei mir. Merkwürdig...
...Ordner /share/pi...
Aber das kann nicht stimmen. Das muss /share/CACHEDEVx_DATA/pi sein. hast Du Dich vertippt oder liegt der Ordner wirklich direkt unter /share?
Oder gilt das nur für das "Testimage"?
Gruss
-
Verstehe gerade nicht, was Du machst
.Hast Du beim letzten Post jetzt lokal auf dem Pi alles durchgeführt?
Weil mount zeigt ja nichts an?
Gruss
Die Seite mit den erweiterten Rechten vergiss am besten, das ist für Windoof.
-
Ja, aber trotzdem: Du hast einen neuen Ordner /media/NFS/testv4 erstellt. Den habe ich nur als Einhängepunkt für den nfs4 Share zur Unterscheidung vom nfsv3 /media/NFS/test erstellt.
Dein dd Befehl gibt aber als Ausgabepfad /media/NFS/test an, das passt dann nicht zum testv4 Verzeichnis?
Außerdem sind das nur Namen, die haben auf die Funktion keinen Einfluss.
Ganz kann ich gerade nicht folgen, was Du wie wo angibst!???
Gruss
Sieht für mich so aus: Du hast war von der qnap was gemountet (testv4), aber dd und mkfs hast Du gegen test ausgeführt, das ist aber lokal auf dem Pi!
-
In meinem Post #25 habe ich bereits alle Befehle in der richtigen Reihenfolge aufgelistet.
Die einzelnen Beispiele sind immer durch hashtags (#) getrennt, das Loopdevice ist als letztes aufgeführt.
Die Abschnitte davor unterscheiden sich nicht wirklich.
Es sind nur die Pfadangaben, die verschieden sind. Das ist aber Linux geschuldet. Das solltest Du Dir vergegenwärtigen.
Gruss
-
Ich habe v3, v4 habe ich nur mal testweise probiert, hat aber zur v3 keinen signifikanten Unterschied.
Gruss
-
-
Oha, hast Du wohl recht. Das kommt davon, wenn man die Steuerzeichen aus dem Putty Log rauswirft.
Zeile 59 ist korrigiert, das war der mkfs-Befehl.
Danke und Gruss
-
Passiert schon mal beim abtippen, aber bei der IP sollte jedem klar sein, des nur ein Dreckfuhler sein kann.
Gruss
-
..so, habe alles akribisch gemacht wie im Post #25 beschrieben und es hat geklappt
.... - DANKE bis hierher..Habe noch ein paar Fragen fürs Verständnis:
Nachdem ich den Ordner auf der pi "/media/qnap" auf den Ordner "/pi" auf der QNAP 192.168.178.41 gemounted habe, erzeuge in den "Imagecontainer" BACKUP über die pi auf der QNAP. Danach erstelle ich auf der pi in BACKUP das .ext4-Filesystem.
Mit losetup /dev/loop0 /media/qnap/backup wird der pi quasi mitgeteilt, dass das loopdevice 0 =loop0 im gemounteten verzeichnis - also auf der QNAP - zu finden ist.
Danach mounte ich das loop0 mit mount /dev/loop0 /media/loopdevice in den Ordner auf der pi (der zuvor erstelle Ordner "loopdevice" befindet sich ja auf der pi in /media/loopdevice)
Und hier verstehe ich es nicht mehr:
Ich mounte zuerst die QNAP in den Ordner /media/qnap - später erzeuge (oder verweise nur darauf?) ich die loopdevice immer noch in dem gleichen Ordner /media/qnap
Mounte dann aber den loop0 in den Ordner /media/loopdevice der auf der pi liegt? Brauche ich den "alten" mount zur QNAP jetzt denn noch? Oder Verweist der gemountete Ordner Loopdevice auf den gemounteten Ordner /media/qnap der ja wiederum auf die QNAP verweist? (es wird jetzt ein Datenträger mit 105 MB im Dateimanager unter den Laufwerken angezeigt und der Ordnername hat sich von "LOOPDEVICE" in "Datenträger 105MB" umbenannt - es ist aber nichts drin)
Muss ich in Zukunft - das Image existiert ja bereits - diese Befehle ausführen?:
sudo mount 192.168.178.41:/pi /media/qnap
sudo losetup /dev/loop0 /media/qnap/backup
sudo mount /dev/loop0 /loopdevice
...wenn ja, wie mache ich das automatisch mit systemctl?
Hier mein Versuch:
Ordner /media/qnap und /media/loopdevice sind bereits erstellt
Gruß - und danke