ubuntuusers.de

Hallo frostschutz

Das Beispiel Pfad/zur/Freigabe 4 funktioniert nicht.

So ist die Eingabe in die exports-Datei korrekt:

Pfad/zur/Freigabe*4.

mit

1

showmount -e 192.168.2.30

wird der Pfad korrekt angezeigt. Der Pfad lässt sich aber nicht mounten.

Grüße aus Südbaden

Das mit dem * ist Quark. Es macht auch keinen Sinn, das gleiche Problem in 2 verschiedenen Threads zu diskutieren.

Hallo Frostschutz,

das ist kein Quark, das ist Tatsache.

Ich habe versucht, in diesem Forum auf die Schwierigkeiten beim mounten hinzuweisen.

In dem anderen Forum versuchte ich die Schwierigkeiten mit der Datei exports zu formulieren.

Mit Deinem Hinweis auf Pfad/zur/Freigabe 4 hast Du doch selbst dagegen verstoßen, in diesem Forum darauf hinzuweisen. Und weil dieser Hinweis falsch ist, habe ich darauf reagiert.

Grüße aus Südbaden

Hallo,

das ist kein Quark, das ist Tatsache.

Es funktioniert an der Stelle (ggf. auch nur zufällig) und ist trotzdem Quark. Der Stern * steht _nicht_ für ein Leerzeichen, sondern für ein oder mehreren Zeichen, siehe z.B. https://tldp.org/LDP/abs/html/special-chars.html und https://tldp.org/LDP/abs/html/globbingref.html. Das ist also keine saubere Lösung für das Leerzeichenproblem.

Eigentlich ist sich das Internet an X anderen Stellen auch einige, dass ein Leerzeichen in Pfaden für mount durch \040 ersetzt werden sollen.

Gruß, noisefloor

Hallo noisefloor

Ich habe tausend Sachen probiert, um mit diesem Befehl

1

showmount -e 192.168.2.30

die korrekte Anzeige des freigegebenen Verzeichnisses zu erhalten. Nur mit dem Stern klappt es. Alles andere funktioniert nicht.

Wenn es doch eine andere Lösung gibt, dann bitte hier veröffentlichen.

In einem anderen Forum, nicht ubuntuusers, hast Du Dich auch mal über Leerstellen beim mounten geäußert. Finde diesen Artikel nicht mehr, aber anscheinend soll es eine Lösung geben, freigegebne Verzeichnisse mit Leerstellen zu mounten.

Grüße aus Südbaden

Hallo,

Wenn es doch eine andere Lösung gibt, dann bitte hier veröffentlichen.

Startet doch mal eine Thread im Supportforum, wo das Thema eigentlich hingehört. Dort gewonnenes Wissen darf dann gerne in Wiki zurückfließen.

Gruß, noisefloor

noisefloor schrieb:

Der Stern * steht […] ist also keine saubere Lösung für das Leerzeichenproblem.

Er ist sogar aus den bereits dargelegten Gründen gar keine Lösung für das Leerzeichenproblem.

Leerzeichen und andere Sonderzeichen in Freigabenamen sind möglich, aber problematisch. Die einfachste saubere Lösung ist, auf so etwas zu verzichten. Wenn man darauf besteht, muss man solche Zeichen durch Quotierung/Maskierung sauber vor unerwünschter Interpretation schützen, und zwar für alle beteiligten Programme. Die Syntax der Quotierung/Maskierung ist programmabhängig:

• mount versteht in der Datei /etc/fstab nur \040 für ein Leerzeichen.

• nfs versteht in der Datei /etc/exports lt. eigener Dokumentation die Begrenzung durch doppelte Anführungszeichen (empfohlen) und \040 für ein Leerzeichen.

• Eine Posix-Shell versteht die bereits genannten und weitere Möglichkeiten; allerdings ist \ für die Shell ebenfalls ein Sonderzeichen und bedarf daher selbst einer speziellen Behandlung.

Der Stern * ist für nfs kein Sonderzeichen und kann natürlich Bestandteil eines Ordnernamens sein. Er steht dann aber nicht für ein Leerzeichen. Ein Freigabename "Eigene*Dateien" gibt also nicht den Ordner "Eigene Dateien" frei, sondern den Ordner "Eigene*Dateien", selbst wenn dieser gar nicht existieren sollte. Das ist zwar möglich, wer aber so etwas Ungeschicktes macht, landet erst recht und zu Recht in der Quotierungshölle.

Nun als fehlerhaft gekennzeichnet.

Hallo zusammem!

k1l schrieb:

Ahoi, wir hatten gerade einen Supportfall, bei dem ein User mit dem Script aus https://wiki.ubuntuusers.de/mount/#Festplatten-Image die Partition aus seinem dd-image nicht mounten konnte.

Das geht mittlerweile mit losetup wesentlich einfacher:

1	losetup --partscan --find --show dd.img

Wenn es jetzt um die erste Partition geht, dann mountet man die mit:

1	mount /dev/loop0p1 /mnt

um diese nachher wieder auszuhängen nimmt man:

1	losetup -d /dev/loop0

So spart man sich den ganzen Kram mit dem offset etc pp.
Sollte man dieses einfach anstatt des Skripts dort auf der Wiki-Seite aufzeigen?

noisefloor schrieb:

Hallo,

einfacher ist immer gut.

Toll wäre natürlich auch, wenn jemand noch zusätzlich einen (kurzen?) Wikiartikel zu losetup schreiben würde.

Gruß, noisefloor

Ich möchte mich hiermit insbesondere auf den vorstehenden Post vom 18. Mai 2017 von k1l beziehen: Es gibt offensichtlich zig Variationen bei der Anwendung von losetup und/oder mount. Dies könnte auch für den hiesigen Wiki-Artikel interessant sein, als Alternative – und damit explizit nicht als Ersatz – zum hiesigen Mount-Skript! Explizit hinweisen möchte ich dabei als Inspiration auf .img-File (disk image) unter Linux mounten – thomasheinz.net 🇩🇪 sowie SOLVED \[stretch] mount: ... overlapping loop device exists - Raspberry Pi Forums 🇬🇧.

Im ersten Fall soll es – Zitat – so gehen:

Um ein Datenträgerabbild bzw. ein disk image im Form einer *.img-Datei unter Linux zu mounten um dann auf dessen Inhalte zugreifen zu können, hat sich für mich folgendes Vorgehen bewährt:

Zuerst einmal ein paar Informationen über das Image anzeigen lassen:

fdisk -l /path/to/img/arch.img

Das ergibt dann folgende Ausgabe:

Disk arch.img: 15.1 GiB, 16172187648 bytes, 31586304 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x00057540

Device Boot Start End Blocks Id System

arch.img1 2048 186367 92160 c W95 FAT32 (LBA)

arch.img2 186368 31586303 15699968 5 Extended

arch.img5 188416 31584255 15697920 83 Linux

Uns interessieren nur die Start-Sektoren, also zum einen der Startsektor 2048 der FAT32 Partition und zum einen der Sektor 188416 der Linux Partition.

Um diese beiden Partitionen zu mounten erstellt man sich zunächst 2 Mountpoints:

mkdir /mnt/sd1

mkdir /mnt/sd2

Dann kann man auch schon die beiden Partitionen mounten. Den Offset mit den zuvor ermittelten Startsektoren anpassen (in meinem Fall 2048 und 188416). Solltet ihr eine andere Sektorgröße als 512 bytes haben, gilt es diesen Wert ebenfalls anzupassen.

mount -t auto -o loop,offset=$((2048*512)) /path/to/img/arch.img /mnt/sd1

mount -t auto -o loop,offset=$((188416*512)) /path/to/img/arch.img /mnt/sd2

Und schon kann man ganz normal über die Mountpoints auf die Daten zugreifen.

Im zweiten Fall soll es – Zitat – dann so gehen:

(...) but when i do whe same step by step (attaching a loop and mounting the loop) be hand, it works:

Code: Select all

$ sudo losetup --offset 4194304 /dev/loop1 /x/2017-07-05-raspbian-jessie-lite.img
$ sudo mount /dev/loop1 /media/boot -o ro
$ sudo losetup --offset 48234496 /dev/loop2 /x/2017-07-05-raspbian-jessie-lite.img
$ sudo mount /dev/loop2 /media/root -o ro
$ sudo losetup -a
/dev/loop1: [45826]:260076 (/x/2017-07-05-raspbian-jessie-lite.img), offset 4194304
/dev/loop2: [45826]:260076 (/x/2017-07-05-raspbian-jessie-lite.img), offset 48234496
$ sudo mount
/dev/loop1 on /media/boot type vfat (ro,relatime...)
/dev/loop2 on /media/root type ext4 (ro,relatime...)
(...)

Bei mir (Ubuntu-MATE-Live-System) ging es nur darum, lediglich eine einzige Image-Partition einzubinden; nicht mehrere und schon gar nicht alle an einen einzigen Einhänge-Punkt!

Im Folgenden kommt ein abgewiesener Befehl sowie eine dmesg-Ausgabe...

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

ubuntu-mate@ubuntu-mate:~$ sudo mount -t auto -o ro,loop,offset=$((8493056*512)) /media/ubuntu-mate/12-TB-Festplatte/disk-Kopie.img /mnt/disk
mount: /mnt/disk: /dev/loop15 konnte nicht im Nur-Lese-Modus eingehängt werden.
       dmesg(1) may have more information after failed mount system call.
ubuntu-mate@ubuntu-mate:~$ man dmesg
ubuntu-mate@ubuntu-mate:~$ sudo dmesg | tail
[25171.450395] EXT4-fs (loop15): write access unavailable, cannot proceed (try mounting with noload)
[25361.723353] loop15: detected capacity change from 0 to 1465147120
[25361.728489] EXT4-fs (loop15): mounted filesystem 4e9f91be-05a9-438f-87a0-7694e3479e12 ro with ordered data mode. Quota mode: none.
[25361.728862] audit: type=1400 audit(1734052953.735:153): apparmor="DENIED" operation="open" class="file" profile="snap.firefox.firefox" name="/etc/fstab" pid=17412 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[25653.468156] EXT4-fs (loop15): unmounting filesystem 4e9f91be-05a9-438f-87a0-7694e3479e12.
[25653.471900] audit: type=1400 audit(1734053245.485:154): apparmor="DENIED" operation="open" class="file" profile="snap.firefox.firefox" name="/etc/fstab" pid=17412 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[25831.024876] loop15: detected capacity change from 0 to 1456656112
[25831.114200] EXT4-fs (loop15): INFO: recovery required on readonly filesystem
[25831.114217] EXT4-fs (loop15): write access unavailable, cannot proceed (try mounting with noload)
[27659.982065] audit: type=1400 audit(1734055252.042:155): apparmor="DENIED" operation="open" class="file" profile="snap.firmware-updater.firmware-notifier" name="/proc/sys/vm/max_map_count" pid=50890 comm="firmware-notifi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
ubuntu-mate@ubuntu-mate:~$ sudo mount -t auto -o ro,loop,offset=$((8493056*512)) /media/ubuntu-mate/12-TB-Festplatte/disk-Kopie.img /mnt/disk
mount: /mnt/disk: /dev/loop15 konnte nicht im Nur-Lese-Modus eingehängt werden.
       dmesg(1) may have more information after failed mount system call.

...wobei ich den ersten Befehl später dann doch erfolgreich ausführen konnte(???)

So, nun komme ich zu „des Pudels Kern“:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

ubuntu-mate@ubuntu-mate:~$ sudo losetup -l -a
NAME        SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                                               DIO LOG-SEC
/dev/loop1          0      0         0  1 /cdrom/casper/minimal.standard.squashfs                   0     512
/dev/loop8          0      0         1  1 /var/lib/snapd/snaps/ubuntu-desktop-bootstrap_171.snap    0     512
/dev/loop6          0      0         1  1 /var/lib/snapd/snaps/firmware-updater_127.snap            0     512
/dev/loop13         0      0         1  1 /var/lib/snapd/snaps/snap-store_1124.snap                 0     512
/dev/loop4          0      0         1  1 /var/lib/snapd/snaps/core22_1380.snap                     0     512
/dev/loop11         0      0         1  1 /var/lib/snapd/snaps/snapd-desktop-integration_157.snap   0     512
/dev/loop2          0      0         0  1 /cdrom/casper/minimal.standard.live.squashfs              0     512
/dev/loop0          0      0         0  1 /cdrom/casper/minimal.squashfs                            0     512
/dev/loop9          0      0         1  1 /var/lib/snapd/snaps/subiquity_5741.snap                  0     512
/dev/loop7          0      0         1  1 /var/lib/snapd/snaps/gnome-42-2204_176.snap               0     512
/dev/loop14         0      0         1  1 /var/lib/snapd/snaps/thunderbird_593.snap                 0     512
/dev/loop5          0      0         1  1 /var/lib/snapd/snaps/firefox_4173.snap                    0     512
/dev/loop12         0      0         1  1 /var/lib/snapd/snaps/snapd_21465.snap                     0     512
/dev/loop3          0      0         1  1 /var/lib/snapd/snaps/bare_5.snap                          0     512
/dev/loop10         0      0         1  1 /var/lib/snapd/snaps/gtk-common-themes_1535.snap          0     512
ubuntu-mate@ubuntu-mate:~$ sudo losetup --offset $((47554560*512)) /dev/loop15 /media/ubuntu-mate/12-TB-Festplatte/disk-Kopie.img
ubuntu-mate@ubuntu-mate:~$ sudo losetup -j /media/ubuntu-mate/12-TB-Festplatte/disk-Kopie.img
/dev/loop15: [2065]:27 (/media/ubuntu-mate/12-TB-Festplatte/disk-Kopie.img), Position 24347934720
ubuntu-mate@ubuntu-mate:~$ sudo mount -o ro /dev/loop15 /mnt/disk
ubuntu-mate@ubuntu-mate:~$ ls -la /mnt/disk
insgesamt 32
drwxr-xr-x   4 root        root         4096 Mai  6  2013 .
drwxr-xr-x   1 root        root           60 Dez 13 01:48 ..
drwx------   2 root        root        16384 Mär 22  2011 lost+found
drwxr-xr-x 117 ubuntu-mate ubuntu-mate 12288 Sep 30 18:30 oom
ubuntu-mate@ubuntu-mate:~$ sudo umount /dev/loop15
ubuntu-mate@ubuntu-mate:~$ ls -la /mnt/disk
insgesamt 0
drwxr-xr-x 2 root root 40 Dez 13 01:48 .
drwxr-xr-x 1 root root 60 Dez 13 01:48 ..
ubuntu-mate@ubuntu-mate:~$ sudo losetup -j /media/ubuntu-mate/12-TB-Festplatte/disk-Kopie.img
/dev/loop15: [2065]:27 (/media/ubuntu-mate/12-TB-Festplatte/disk-Kopie.img), Position 24347934720
ubuntu-mate@ubuntu-mate:~$ sudo losetup -d /dev/loop15
ubuntu-mate@ubuntu-mate:~$ sudo losetup -j /media/ubuntu-mate/12-TB-Festplatte/disk-Kopie.img
ubuntu-mate@ubuntu-mate:~$ sudo losetup -l -a
NAME        SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                                               DIO LOG-SEC
/dev/loop1          0      0         0  1 /cdrom/casper/minimal.standard.squashfs                   0     512
/dev/loop8          0      0         1  1 /var/lib/snapd/snaps/ubuntu-desktop-bootstrap_171.snap    0     512
/dev/loop6          0      0         1  1 /var/lib/snapd/snaps/firmware-updater_127.snap            0     512
/dev/loop13         0      0         1  1 /var/lib/snapd/snaps/snap-store_1124.snap                 0     512
/dev/loop4          0      0         1  1 /var/lib/snapd/snaps/core22_1380.snap                     0     512
/dev/loop11         0      0         1  1 /var/lib/snapd/snaps/snapd-desktop-integration_157.snap   0     512
/dev/loop2          0      0         0  1 /cdrom/casper/minimal.standard.live.squashfs              0     512
/dev/loop0          0      0         0  1 /cdrom/casper/minimal.squashfs                            0     512
/dev/loop9          0      0         1  1 /var/lib/snapd/snaps/subiquity_5741.snap                  0     512
/dev/loop7          0      0         1  1 /var/lib/snapd/snaps/gnome-42-2204_176.snap               0     512
/dev/loop14         0      0         1  1 /var/lib/snapd/snaps/thunderbird_593.snap                 0     512
/dev/loop5          0      0         1  1 /var/lib/snapd/snaps/firefox_4173.snap                    0     512
/dev/loop12         0      0         1  1 /var/lib/snapd/snaps/snapd_21465.snap                     0     512
/dev/loop3          0      0         1  1 /var/lib/snapd/snaps/bare_5.snap                          0     512
/dev/loop10         0      0         1  1 /var/lib/snapd/snaps/gtk-common-themes_1535.snap          0     512
ubuntu-mate@ubuntu-mate:~$

Also insgesamt 11 Befehle (davon einige zwecks Kontrolle doppelt und dreifach) 😎 . Den Offset habe ich dabei automatisch berechnen lassen.

Achso: Loop-Geräte wie /dev/loop0p1 haben bei mir auch nicht funktioniert („für /media/ubuntu-mate/12-TB-Festplatte/disk-Kopie.img existieren sich überschneidende Loop-Geräte.“).

Meine gesamten diesbezüglichen Aktionen habe ich übrigens unter 20241213_Image-Partition_mounten in der Ablage gespeichert.

▶ Ich hoffe, dass das Vorstehende für Euch jetzt nicht zu viel und/oder wirr war...

Diese Möglichkeiten von losetup sind interessant, gehören aber gar nicht in den Artikel zu mount, sondern in einen eigenen Artikel zu losetup.

Das Programm schafft losetup schafft nur die Voraussetzungen für eine Einbindung und bindet selbst nicht ein.

Hallo kB, Du schriebst:

Diese Möglichkeiten von losetup sind interessant, gehören aber gar nicht in den Artikel zu mount, sondern in einen eigenen Artikel zu losetup.

Ja, Zustimmung; eine weitere – die erwähnte wg. Überschneidung nicht von vornherein ausschließende – Möglichkeit wäre auch noch das (ggf. zusätzliche) Anlegen eines „Image-Datei“-Artilels (wobei ich mich vom Namen – aber nicht unbedingt von der Struktur – her an Image-Datei anlehne). In diesen – und/oder (je nach Einzelfall, was jeweils auszuloten wäre) den Artikel zu losetup – könnten dann ggf. die Abschnitte mount (Abschnitt „Festplatten-Image“) sowie mount (Abschnitt „Festplatten-Image-mit-LVM“) ausgelagert werden. Hier in mount könnten dann die entsprechenden Abschnitte nach dem Beispiel von mount (Abschnitt „RAM-Disks“) entsprechend verlinkt werden.

Ebenso wäre es m.E. gemäß dem vorstehend Ausgeführtem evtl. eine Möglichkeit, die Abschnitte dd (Abschnitt „Mit-dd-erstellte-Images-einbinden“) sowie dd (Abschnitt „Partition-aus-einem-Image-der-gesamten-Platte-einbinden“) auszulagern und entsprechend zu verlinken. Insgesamt ist dabei auch noch zu beachten, dass Image-Dateien nicht nur mittels dd, sondern auch mittels gddrescue erstellt werden können – wobei Letzteres aber (noch) nicht im gddrescue-Artikel erklärt wird.

Der Vollständigkeit halber: Hier im Wiki existiert bereits ein ISO-Image-Artikel. Evtl. könnten von diesem Teile in den neuen „Image-Datei“-Artilel verlagert werden, z.B. (teilweise) ISO-Image (Abschnitt „Andere-Imageformate“). Allerdings irritiert mich, dass im ISO-Abbild-Artikel oben rechts im Info-Kasten unter „Dateiendung“ .cdr, .dvdr, .img, .iso aufgeführt sind, also auch „.img“. MIME-Types sind entsprechend application/x-cd-image, application/x-iso-image und application/x-iso9660-image. Im Image-Datei-Artikel fehlt leider ein entsprechender Info-Kasten. Frage: Ist eine Image-Datei also das gleiche wie ein ISO-Abbild? Falls dies der Fall wäre, bräuchte es nämlich keinen zusätzlichen „Image-Datei“-Artilel, sondern der ISO-Image-Artikel könnte entsprechend erweitert werden. Zu klären wäre, nach welchem Format – bzw. welcher Norm – dd und gddrescue ihre Abbilder (.img bzw. .iso) erstellen. Zumindest bei der Image-Erstellung mit dd scheinen jedoch die Daten des Quell-Datenträgers bzw. der Quell-Partition lediglich in eine neue Hülle (der .img bzw. .iso-Datei) umkopiert zu werden. Mein mittels gddrescue erstelltes Festplatten-Abbild hat laut Caja den Typ „Rohes Datenträgerabbild (application/vnd.efi.img)“. Also scheint nach meinen Recherchen die Antwort zu sein, dass eine Image-Datei nicht das gleiche wie ein ISO-Abbild ist, es also durchaus einen zusätzlichen „Image-Datei“-Artilel geben könnte! Der Artikel zu losetup könnte dann gemäß hdparm auch gewissermaßen eine erweiterte Manpage werden.

Das Programm schafft losetup schafft nur die Voraussetzungen für eine Einbindung und bindet selbst nicht ein.

Richtig. Und es hängt auch nicht selbständig aus, wie man z.B. in Zeile 439ff meiner Ablage-Datei 20241213_Image-Partition_mounten sehen kann. Dazu braucht es nämlich den umount-Befehl, wie man an Zeile 506ff sehen kann. Nach Anwenden des umount-Befehls sollte allerdings immer mittels sudo losetup -j /Pfad/zur/Image-Datei überprüft werden, ob Letztere noch an eine Geräte-Datei angebunden ist oder nicht. Teilweise habe ich es nämlich schon gehabt (was nicht in meiner Ablage-Datei dokumentiert ist), dass nach Anwenden des umount-Befehls diese Bindung automatisch mitgelöst war. Falls sie aber noch immer angebunden ist, schafft der Befehl sudo losetup -d /dev/loopXX (wobei XX für eine entsprechende Zahl steht) Abhilfe!