Du bist nicht angemeldet.
Hallo,
neuerdings funktioniert das Mounten des /media/sf_transfer in meinem /home-Verzeichnis nicht mehr.
$ 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.
Woran kann das liegen?
Gruß
Ch. Hanisch
Beitrag geändert von Hanisch (22.12.2018 11:12:33)
Offline
Die Meldung kann eigentlich nur bedeuten: /home/opa/Shared_transfer existiert schon zum Zeitpunkt des Mountversuchs.
ls -l /home/opa/
Offline
Hallo,
Die Meldung kann eigentlich nur bedeuten: /home/opa/Shared_transfer existiert schon zum Zeitpunkt des Mountversuchs.
ls -l /home/opa/
Aber natürlich existiert das Verzeichnis ~/Shared_transfer bereits. Ohne das würde der Mount-Befehl ohnehin nicht funktionieren.
Gruß
Ch. Hanisch
PS: Wie melde ich vom ArchLinux Forma ab?
Offline
Da steht aber: Die Datei existiert bereits. Wenn es ein Verzeichnis wäre, würde es gehen, oder eine andere Fehlermeldung geben.
Offline
Da steht aber: Die Datei existiert bereits. Wenn es ein Verzeichnis wäre, würde es gehen, oder eine andere Fehlermeldung geben.
Nein es ist ein Verzeichnis.
$ ls -l /home/opa/
insgesamt 72
-rw-r--r-- 1 opa users 386 31. Jan 2017 aur-64Bit.lst
-rw-r--r-- 1 root root 464 28. Jan 2017 aur.lst
drwxr-xr-x 2 opa users 4096 23. Feb 2016 Bilder
drwxr-xr-x 2 opa users 4096 19. Dez 18:10 Desktop
drwxr-xr-x 2 opa users 4096 6. Feb 2017 Dokumente
drwxrwxrwx 3 opa root 4096 8. Nov 2017 Downloads
drwxr-xr-x 2 opa users 4096 13. Sep 2016 fluid-soundfont
drwxr-xr-x 2 opa users 4096 19. Sep 2016 Musik
drwxr-xr-x 2 opa users 4096 24. Nov 2015 Öffentlich
-rw-r--r-- 1 root root 3646 28. Jan 2017 pacman.lst
drwxr-x--- 2 opa users 4096 27. Okt 2016 Projects
drwxr-xr-x 2 opa users 4096 12. Jan 2016 scanner
drwxr-xr-x 2 opa users 4096 19. Dez 18:05 Shared_transfer
drwxr-xr-x 4 root root 4096 28. Jan 2017 SYSTEM
drwxr-xr-x 2 opa users 4096 19. Dez 17:58 usr
drwxr-xr-x 2 opa users 4096 22. Nov 2015 Videos
drwxr-xr-x 2 opa users 4096 29. Okt 2015 Vorlagen
drwxr-xr-x 3 opa users 4096 31. Jan 2017 WORK
Gruß
Ch. Hanisch
Offline
- Was meldet denn
file Shared_transfer
?
- Was passiert, wenn Du das Verzeichnis löschst und neu anlegst?
- Wurden alle vbox-Module beim Start korrekt geladen?
Online
Hallo,
- Was meldet denn
file Shared_transfer
?
- Was passiert, wenn Du das Verzeichnis löschst und neu anlegst?
Habe ich bereits gemacht - ohne Erfolg.
- Wurden alle vbox-Module beim Start korrekt geladen?
Wie stelle ich das fest?
In /media/sf_transfer sind alle Verzeichnisse/Dateien aus dem Host vorhanden.
Gruß
Ch. Hanisch
Offline
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
Offline
Ä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.
Beitrag geändert von hcjl (20.12.2018 15:42:19)
Online
Hallo,
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
Beitrag geändert von Hanisch (20.12.2018 18:15:05)
Offline
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?
Offline
In Deinem letzten Beitrag schreibst Du "reinstalliert". Beides sollte aktualisiert werden. Welche Versionen laufen denn auf Host und Guest?
Online
Hallo,
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
Beitrag geändert von Hanisch (21.12.2018 13:55:43)
Offline
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!
Hallo,
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
Offline
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.
Hallo,
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
Beitrag geändert von Hanisch (22.12.2018 11:18:25)
Offline
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.
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.
Offline
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.
Hallo,
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
Offline
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.