Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

Wei1nah2
23.12.2018 14:49:56

Ich gehe davon aus, dass mein Hinweis auf mehrfaches Einhängen als Lösung zielführend war und du deinen Fehler erkannt hast. Wie die Meldung letztlich formuliert wird, ist irrelevant. Fakt ist, dass mehrfaches Einhängen nicht möglich ist.

Nachdem du das Thema selber auf "gelöst" gesetzt  hast, sehe ich hier keinen weiteren Diskussionsbedarf.

Hanisch
23.12.2018 14:24:20

Hallo,

Wei1nah2 schrieb:

Wenn ich das manuelle Mounten wiederhole, bekomme ich wieder die offensichlich falsche Fehlermeldung:

$ sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer

$ sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer
mount: /home/opa/Shared_transfer: mount(2) Systemaufruf ist fehlgeschlagen: Die Datei existiert bereits.

Was ist daran falsch? Es ist ein Fehler, dass ein bereits eingehängtes Verzeichnis noch einmal eingehängt werden soll, also erscheint die Fehlermeldung. Alles so wie es muss und wie man es auch erwartet.

"Was ist daran falsch?" Alles.

$ sudo blkid
/dev/sda1: LABEL="Arch" UUID="5c07f793-2c6e-4051-be69-a01c008fdfa3" TYPE="ext4" PARTUUID="24fc80c9-01"
/dev/sda2: LABEL="SWAP" UUID="a63c63ac-a361-42f4-8ab4-05a830bc99c3" TYPE="swap" PARTUUID="24fc80c9-02"
/dev/sda3: LABEL="ArchHome" UUID="71d7eab7-9532-4a40-9566-89b69b8c4cc6" TYPE="ext4" PARTUUID="24fc80c9-03"
/dev/sdb1: LABEL="Daten-Transfer" UUID="67157bf6-c475-4480-b779-3c12c25aea0c" TYPE="ext4" PARTUUID="00067f14-01"

$ sudo mount /dev/sdb1 /media/x
$ sudo mount /dev/sdb1 /media/x
mount: /media/x: /dev/sdb1 ist bereits auf /media/x eingehängt.

Natürlich kann man ein Gerät mehrfach einhängen, dann kommt eben obige Meldung - Fertig!


Gruß

Ch. Hanisch

Wei1nah2
22.12.2018 13:16:39

Ich kann trotzdem keinen Nutzen darin erkennen, warum man dasselbe Verzeichnis einmal mit root- und dann noch mal mit Benutzerrechten einhängen soll, da sind Konflikte doch absehbar. Entweder kann jeder über die Benutzerfreigabe an das Verzeichnis, dann hilft auch die Beschränkung auf root bei einer anderen Freigabe nichts, oder umgekehrt. In sofern ist das ganze Szenario völlig praxisfremd, egal wie gut oder schlecht die daraus resultierende Meldung auch formuliert ist.

drcux
22.12.2018 13:06:40

Zugegeben: Die Fehlermeldung ist nicht sehr gut gewählt, vielleicht ein Übersetzungsfehler...

Das es bei anderen Distries noch geht, könnte daran liegen, das Arch die Linux-Utils/VBox-Guest-Modules ständig aktualisiert und die Entwickler in den letzten Wochen etwas geändert haben könnten.

Wenn man ein Rolling Release Linux nutzt, muss man mit so etwas leben.

Wei1nah2
22.12.2018 12:37:24
Hanisch schrieb:

Ja, genau, das ist die unverständliche Neuerung bei ArchLinux.

Es gibt keine "Neuerungen"

Das hat bisher und überall funktioniert mit sowohl automount als auch dem nachträglichen manuellen Einhängen.

Das ist eine unbewiesene Behauptung

Beides geht nun in ArchLinux nicht mehr

Das ging noch nie

Warum diese Abweichung gegenüber anderen Distributionen?

Da musst du die "anderen Distributionen" fragen, bei Arch läuft alles korrekt. Und wenn dir das nicht passt, nimm halt die anderen Distributionen, die das deiner Meinung nach können.

Wenn ich das manuelle Mounten wiederhole, bekomme ich wieder die offensichlich falsche Fehlermeldung:

$ sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer

$ sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer
mount: /home/opa/Shared_transfer: mount(2) Systemaufruf ist fehlgeschlagen: Die Datei existiert bereits.

Was ist daran falsch? Es ist ein Fehler, dass ein bereits eingehängtes Verzeichnis noch einmal eingehängt werden soll, also erscheint die Fehlermeldung. Alles so wie es muss und wie man es auch erwartet.

Hanisch
22.12.2018 12:10:44

Hallo,

Wei1nah2 schrieb:

Nein, wird es nicht, das hast du so in den Einstellungen der gemeinsamen Ordner in der VM eingtragen, und ich frage noch mal nach dem Sinn.

Ja, narürlich wird das nur dann automatisch eingehängt, wenn ich in

VirtualBox -> Ändern -> Gemeinsame Ordner -> Ändern des ausgewählten gemeinsamen Ordners -> Haken rein bei "Automatisch einbinden"

angebe. Dann wird Shared Folder in /media/sf_tranfer als root eingebunden.

Mit dem Befehl:

sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer

mache ich den Inhalt des Shared Folder für den User mit seinen Rechten zugänglich.

Dann lass den automount weg!

Ja, genau, das ist die unverständliche Neuerung bei ArchLinux.
Das hat bisher und überall funktioniert mit sowohl automount als auch dem nachträglichen manuellen Einhängen.
Beides geht nun in ArchLinux nicht mehr. Warum diese Abweichung gegenüber anderen Distributionen?

Wenn ich das manuelle Mounten wiederhole, bekomme ich wieder die offensichlich falsche Fehlermeldung:

$ sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer

$ sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer
mount: /home/opa/Shared_transfer: mount(2) Systemaufruf ist fehlgeschlagen: Die Datei existiert bereits.

Gruß

Ch. Hanisch

Wei1nah2
22.12.2018 01:10:28
Hanisch schrieb:

Nein, automatisch wird Shared Folder von den GuestAdditions in /media/sf_tranfer als root eingehängt.

Nein, wird es nicht, das hast du so in den Einstellungen der gemeinsamen Ordner in der VM eingtragen, und ich frage noch mal nach dem Sinn.

Mit dem Befehl:

sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer

mache ich den Inhalt des Shared Folder für den User mit seinen Rechten zugänglich.

Dann lass den automount weg!

Das hat bisher und überall funktioniert.

Unbewiesene Behauptung und deshalb hier irrelevant.

Hanisch
22.12.2018 00:58:45

Hallo,

Wei1nah2 schrieb:

Warum wird nach einem bereits erfolgreichen

Dez 19 20:55:34 Arch VBoxService[321]: 00:00:00.060974 automount vbsvcAutoMountWorker: Shared folder 'transfer' was mounted to '/media/sf_transfer'

noch einmal versucht, dieselbe Freigabe ein weiteres mal manuell einzuhängen? Entweder automatisch oder manuell, aber nicht beides, sonst muss man sich über das Ergebnis nicht wundern!

Nein, automatisch wird Shared Folder von den GuestAdditions in /media/sf_tranfer als root eingehängt.

Mit dem Befehl:

sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer

mache ich den Inhalt des Shared Folder für den User mit seinen Rechten zugänglich.
Das hat bisher und überall funktioniert.

Gruß

Ch. Hanisch

Wei1nah2
22.12.2018 00:49:10
Hanisch schrieb:

Das sieht mir alles sehr nach einer Macke im 'mount' in ArchLinux aus.

Das sieht mir alles eher nach PEBKAC aus.

Warum wird nach einem bereits erfolgreichen

Dez 19 20:55:34 Arch VBoxService[321]: 00:00:00.060974 automount vbsvcAutoMountWorker: Shared folder 'transfer' was mounted to '/media/sf_transfer'

noch einmal versucht, dieselbe Freigabe ein weiteres mal manuell einzuhängen? Entweder automatisch oder manuell, aber nicht beides, sonst muss man sich über das Ergebnis nicht wundern!

Hanisch
21.12.2018 13:37:06

Hallo,

stefanhusmann schrieb:

Suche nach der Datei mount.vboxsf und lösche sie oder benenne sie um. Dann starte den Service neu. Existieren die Verzeichnisse »/var/run/vboxadd« und »/home/smbuser« wirklich nicht?

sudo mv /usr/lib64/virtualbox/mount.vboxsf  /usr/lib64/virtualbox/mount.vboxsf.OFF
sudo reboot

ändert leider nichts.

Die Verzeichnisse  »/var/run/vboxadd« und »/home/smbuser« existieren nicht und die habe ich auch noch nie gebraucht.

Bei anderen Distributionen funktioniert

sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer

ohne Probleme. Auch bei ArchLinux (64Bit) in der VM ging es bis vor Kurzem noch.

Von Seiten VirtualBox 5.2.22 im Manjaro-Host funktionieren die Shared Folder, denn in /media/sf_transfer   sind die Verzeichnisse/Dateien aus dem Host ~/transfer alle vorhanden.

Nach

sudo pacman -S  virtualbox-guest-dkms  virtualbox-guest-utils

wird die Datei  /usr/lib64/virtualbox/mount.vboxsf  wieder neu angelegt.

Das sieht mir alles sehr nach einer Macke im 'mount' in ArchLinux aus.


Gruß
Ch. Hanisch

hcjl
21.12.2018 12:22:32

In Deinem letzten Beitrag schreibst Du "reinstalliert". Beides sollte aktualisiert werden. Welche Versionen laufen denn auf Host und Guest?

stefanhusmann
21.12.2018 08:37:13

Ich kenne mich mit virtualbox nicht aus, aber diese Meldungen scheinen die entscheidenden  zusein:

Old binary mount data not supported, remove obsolete mount.vboxsf and/or update your VBoxService.

Verzeichnis »/var/run/vboxadd« existiert nicht.
Verzeichnis  »/home/smbuser« existiert nicht.

Suche nach der Datei mount.vboxsf und lösche sie oder benenne sie um. Dann starte den Service neu. Existieren die Verzeichnisse »/var/run/vboxadd« und »/home/smbuser« wirklich nicht?

Hanisch
20.12.2018 18:50:46

Hallo,

hcjl schrieb:

Vielleicht reicht schon ein Aktualisieren der installierten VB-Pakete auf Host und Guest aus.

Im Gast:

$ sudo pacman -S virtualbox-guest-dkms virtualbox-guest-utils

bringt keine Veränderung.
Und auch ein Reinstallieren von VirtualBox im Host bringt nichts.

Was kann ich da noch machen?

Merkwürdigerweise lautet die Fehlermeldung:

$ sudo mount -t vboxsf -o rw,uid=1000,gid=1000 transfer /home/opa/Shared_transfer
mount: /home/opa/Shared_transfer: mount(2) Systemaufruf ist fehlgeschlagen: Die Datei existiert bereits.

Wo es sich doch garantiert um keine Datei, sondern ein Verzeichnis handelt.
Der Mount-Befehl arbeitet doch grundsätzlich nur für Verzeichnisse, wo dann Datenträger "eingehängt" werden. 

Gruß
Ch. Hanisch

hcjl
20.12.2018 16:41:35

Äh, da steht doch eigentlich alles, was Du brauchst, um das Problem zu lösen. Vielleicht reicht schon ein Aktualisieren der installierten VB-Pakete auf Host und Guest aus.

Hanisch
19.12.2018 22:25:05

Hallo,

hier habe ich einige Informationen vom Hochfahren:

$ sudo journalctl  -b
...
Dez 19 20:55:28 Arch kernel: vboxguest: misc device minor 57, IRQ 20, I/O port d040, MMIO at 0x00000000f0400000 (size 0x0000000000400000)
Dez 19 20:55:28 Arch kernel: vboxsf: loading out-of-tree module taints kernel.
Dez 19 20:55:28 Arch kernel: vboxsf: module verification failed: signature and/or required key missing - tainting kernel
Dez 19 20:55:28 Arch kernel: Linux agpgart interface v0.103
Dez 19 20:55:28 Arch kernel: audit: type=1130 audit(1545249311.586:6): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-sysusers commDez 19 20:57:06 Arch kernel: sysfs: cannot create duplicate filename '/devices/virtual/bdi/vboxsf-transfer'
="systemd" e>
Dez 19 20:55:28 Arch kernel: vboxvideo: module is from the staging directory, the quality is unknown, you have been warned.
...

Dez 19 20:55:34 Arch kernel: vboxsf: Old binary mount data not supported, remove obsolete mount.vboxsf and/or update your VBoxService.
Dez 19 20:55:34 Arch VBoxService[321]: 00:00:00.060974 automount vbsvcAutoMountWorker: Shared folder 'transfer' was mounted to '/media/sf_transfer'
Dez 19 20:55:34 Arch dhcpcd[312]: enp0s3: soliciting a DHCP lease
Dez 19 20:55:34 Arch sh[324]: Benutzer »vboxadd«: Verzeichnis »/var/run/vboxadd« existiert nicht.
Dez 19 20:55:34 Arch sh[324]: Benutzer »smbuser«: Verzeichnis »/home/smbuser« existiert nicht.
...

Dez 19 20:57:06 Arch kernel: sysfs: cannot create duplicate filename '/devices/virtual/bdi/vboxsf-transfer'

Vielleicht kann man damit etwas anfangen?

Gruß

Ch. Hanisch

Fußzeile des Forums

Powered by FluxBB