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
Die Meldung kann eigentlich nur bedeuten: /home/opa/Shared_transfer existiert schon zum Zeitpunkt des Mountversuchs.

ls -l /home/opa/
Hallo,
stefanhusmann schriebDie 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?
Da steht aber: Die Datei existiert bereits. Wenn es ein Verzeichnis wäre, würde es gehen, oder eine andere Fehlermeldung geben.
stefanhusmann schriebDa 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
- 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?
Hallo,
hcjl schrieb- 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
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
Ä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.
Hallo,
hcjl schriebVielleicht 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
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?
In Deinem letzten Beitrag schreibst Du "reinstalliert". Beides sollte aktualisiert werden. Welche Versionen laufen denn auf Host und Guest?
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
  • [gelöscht]

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!
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
  • [gelöscht]

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.
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
  • [gelöscht]

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.
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.
  • [gelöscht]

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.