ubuntuusers.de

Ich wollte nur vermeiden, dass die Option --bind verschwindet ...

Das war gar nie meine Absicht gewesen. Im Gegenteil, ich verwende selbst die Option auch. Dies nicht zuletzt deshalb, weil ja auf Samba- und NFS-Servern "wide links" (d.h. Symlinks, die aus einer Freigabe hinaus führen) immer sehr problematisch sind.

Ansonsten kann ich Deine Feststellung, Symlinks seien weniger stabil als mount --bind nicht nachvollziehen. In jedem Linux-Betriebssystem (auch Ubuntu) gibt es Hunderte von Symlinks. Dass diese deshalb nicht stabil sind, kann man wohl nicht behaupten.

mount --bind als Ersatz für Symlinks in Dateisystemen, die Symlinks nicht unterstützen (AFAIK ist das nur noch VFAT) wollte ich bewusst nicht erwähnen. Von der Verwendung solcher Dateisysteme sollte man eher abraten.

Was ich kritisiert habe, ist dass mich die beiden Beispiele so nicht überzeugen konnten, weil ich bei diesen keinen Vorteil von mount --bind erkennen kann.

Ein Beispiel für mount --move fehlt bisher ganz. Da fällt mir im Moment auch nichts Gescheidtes ein – außer vielleicht eben das Auslagern einer Systemdatei auf eine andere Partition/Platte. Aber wer macht denn so etwas schon?

Wie Du siehst, bin ich auch auf der Suche nach guten Beispielen. Aber überzeugend sollten diese eben sein, nicht nur machbar.

fuer die mehrzahl an usern waere es sinnvoll, wenn irgendwo einmal blkid erwaehnung faende.

wenn irgendwo einmal blkid erwaehnung faende.

Dafür gibt es doch sogar einen eigenen Wiki-Artikel blkid. Außerdem wird es im Artikel fstab unter Identifikation der Geräte gut sichtbar erwähnt. Doch es spricht sicher nichts dagegen, auch hier im Artikel mount noch einmal darauf hinzuweisen.

EDIT:

done.

Max-Ulrich_Farber schrieb:

Doch es spricht sicher nichts dagegen, auch hier im Artikel mount noch einmal darauf hinzuweisen.

Hallo, ich finde es nicht so passend und zu dick aufgetragen, dafür eine Befehlsvorlage zu verwenden, die gehört m.E. in den Artikel blkid. Mein Vorschlag wäre, den davor stehenden Satz etwa so zu ergänzen:
..., die man über sudo blkid ermitteln kann.

Hallo stahlwollschaf,

Du hast kürzlich den Artikel folgendermaßen ergänzt:

Die Option exec muss nach der Option user bzw. users angegeben werden, da ansonsten automatisch die Optionen noexec, nosuid und nodev gesetzt werden. Die Angabe der Option an einer späteren Position überschreibt die Default-Option.

Ich verstehe nicht genau, wie die Position von user bzw. users ggü. exec das Überschreiben von default beeinflussen soll. Bist Du Dir da wirklich sicher, und an welcher Position steht dann default? Wenn diese einseitige "Überschreiblogik" tatsächlich existiert, wird sie doch in irgendwelchen "offiziellen" Dokumenten, z.B. mount, bestimmt erwähnt, worauf man dann auch verweisen sollte, weil da vielleicht noch weitere Regeln bzgl. des Überschreibens stehen.

Ich frage deshalb, weil ich mich da auch schon mal geirrt hatte: 7566003:

Hallo,

ich habe dazu gerade nichts gefunden, also das die Reihenfolge der Optionen wichtig ist. Würde mich auch wundern.

user als Option bedeutet aber implizit auch noexec - das steht auch in der Doku. Sprich user und exec widersprechen sich. Das Arch Wiki warnt sogar vor der gemeinsamen Verwendung:

Note: If you intend to use the exec flag with automount, you should remove the user flag for it to work properly as found in the course of a Fedora Bug Report

Gruß, noisefloor

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?

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

Hinweis zu SMB-Netzwerklaufwerken ab Ubuntu 17.10 Artful Aardvark unter „Virtuelle Netzwerkdateisysteme“ hinzugefügt: Option vers=1.0 (=SMB-Version 1.0) muss nun bei Altgeräten angegeben werden, da nicht mehr Standard bei mount.cifs. Betrifft z.B. FritzBox.

Max-Ulrich_Farber schrieb:

Die Verwendung von systemd bedeutet eine tiefgreifende Veränderung eines Linux-Systems, deren Tragweite mir erst langsam bewusst wird. Da werden noch einige Änderungen oder Ergänzungen im Wiki nötig werden. Zum Beispiel auch im Artikel mount,

Was würdest du hier verändern wollen?

denn ganz allgemein verhalten sich mittels Systemd eingebundene Partitionen oder Shares anders als "frei" gemountete.

Korrekt. → systemd/mount units

Sie können z.B. nicht mittels sudo umount wieder ausgehängt werden

Stimmt leider nicht ganz. Sie können nur nicht mit mount wieder eingehängt werden ▶ Problemlösung

Viele Grüße

BillMaier

UlfZibis schrieb:

Hallo stahlwollschaf,

Du hast kürzlich den Artikel folgendermaßen ergänzt:

Die Option exec muss nach der Option user bzw. users angegeben werden, da ansonsten automatisch die Optionen noexec, nosuid und nodev gesetzt werden. Die Angabe der Option an einer späteren Position überschreibt die Default-Option.

Ich verstehe nicht genau, wie die Position von user bzw. users ggü. exec das Überschreiben von default beeinflussen soll. Bist Du Dir da wirklich sicher, und an welcher Position steht dann default? Wenn diese einseitige "Überschreiblogik" tatsächlich existiert, wird sie doch in irgendwelchen "offiziellen" Dokumenten, z.B. mount, bestimmt erwähnt, worauf man dann auch verweisen sollte, weil da vielleicht noch weitere Regeln bzgl. des Überschreibens stehen.

Ich frage deshalb, weil ich mich da auch schon mal geirrt hatte: 7566003:

Einfluss der Reihenfolge kann ich ab mount version 2.36 definitiv nicht mehr bestätigen. Ab 2.36 wird Option exec einfach ignoriert und noexec aktiv gesetzt, wenn Option users gesetzt ist. Auch wenn exec gesetzt ist. Unangenehm fuer TOR, das will gerne aus ~ aufgerufen werden, welches z.B. wegen LUKS an einem mount haengt. Betrifft Dez2020 teilweise U20.04 und dann folgende.

Leerstelle in einem freigegeben Verzeichnis.

Ich versuche einen von NFS freigegeben Ordner mit Leerstelle zu mounten.

In der Datei /etc/exports habe ich anstatt der Leerstelle ein * eingefügt. Auf diese Art wird mir der freigegebene Ordner korrekt angezeigt.

Das mounten funktioniert allerdings nicht. So sieht der Befehl aus:

1

sudo mount 192.168.2.30:'/mnt/Eigene Dateien' /home/user/Schreibtisch/mount

Fehlermeldung:

reason given by server: No such file or directory.

Ohne halbe Anführungszeichen (wie nennt man die eigentlich?) funktioniert der Befehl auch nicht.

Kann der Befehl mount wirklich keine Ordner einbinden, die ein Leerzeichen enthalten?

Wenn das wirklich stimmt, sollte vielleicht auch der Wiki-Artikel ergänzt werden.

Grüße aus Südbaden

Versuch dein Glück mit '/mnt/Eigene\040Dateien' oder einfach so noch \ vor dem Leerzeichen

Hallo frostschutz,

Das ging ja super schnell.

Funktioniert leider nicht. Der Dateiname wird mit halben Anführungszeichen so interpretiert: /mnt/Eigene\040Dateien.

Ohne halbe Anführungszeichen: /mnt/Eigene040Dateien.

Mit Backflash ohne Leerstelle so: /mnt/EigeneDateien.

Mit Backflash und mit Leerstelle meckert mount mit: fehlerhafter Aufruf.

Grüße aus Südbaden

Okay, das \040 ist für einen Eintrag in /etc/fstab (oder auch /etc/exports, wobei die Manpage hier "" Double-Quotes empfiehlt). NFS hat auch ein Beispiel für einen Pfad mit Leerzeichen ("/PFAD/ZUR/FREIGABE 4")

Auf der Kommandozeile reicht bei mir das normale Quoting (also der Befehl den du eingangs gezeigt hast).