staging.inyokaproject.org

mount

Status: Ungelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |
Dieses Thema ist die Diskussion des Artikels mount.

Max-Ulrich_Farber

Avatar von Max-Ulrich_Farber

Anmeldungsdatum:
23. Januar 2007

Beiträge: 7787

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.

Dan-yell

Anmeldungsdatum:
4. März 2010

Beiträge: Zähle...

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

Max-Ulrich_Farber

Avatar von Max-Ulrich_Farber

Anmeldungsdatum:
23. Januar 2007

Beiträge: 7787

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.

UlfZibis

Anmeldungsdatum:
13. Juli 2011

Beiträge: 2726

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.

UlfZibis

Anmeldungsdatum:
13. Juli 2011

Beiträge: 2726

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:

noisefloor Team-Icon

Ehemaliger
(Themenstarter)
Avatar von noisefloor

Anmeldungsdatum:
6. Juni 2006

Beiträge: 28316

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

k1l

Avatar von k1l

Anmeldungsdatum:
22. September 2006

Beiträge: 1253

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 Team-Icon

Ehemaliger
(Themenstarter)
Avatar von noisefloor

Anmeldungsdatum:
6. Juni 2006

Beiträge: 28316

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

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 7816

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.

BillMaier Team-Icon

Supporter

Anmeldungsdatum:
4. Dezember 2008

Beiträge: 6389

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

opinion_no9

Anmeldungsdatum:
12. November 2017

Beiträge: Zähle...

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.

Antworten |