Du bist nicht angemeldet.

#1 19.12.2018 19:28:29

Hanisch
Mitglied

[Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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 12:12:33)

Offline

#2 19.12.2018 19:58:50

stefanhusmann
Moderator

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

Die Meldung kann eigentlich nur bedeuten: /home/opa/Shared_transfer existiert schon zum Zeitpunkt des Mountversuchs.

ls -l /home/opa/

Offline

#3 19.12.2018 20:02:09

Hanisch
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

Hallo,

stefanhusmann schrieb:

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

#4 19.12.2018 20:04:53

stefanhusmann
Moderator

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

Da steht aber: Die Datei existiert bereits. Wenn es ein Verzeichnis wäre, würde es gehen, oder eine andere Fehlermeldung geben.

Offline

#5 19.12.2018 20:11:13

Hanisch
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

stefanhusmann schrieb:

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

#6 19.12.2018 20:28:21

hcjl
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

- 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

#7 19.12.2018 20:31:20

Hanisch
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

Offline

#8 19.12.2018 22:25:05

Hanisch
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

#9 20.12.2018 16:41:35

hcjl
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

Ä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 16:42:19)

Online

#10 20.12.2018 18:50:46

Hanisch
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

Beitrag geändert von Hanisch (20.12.2018 19:15:05)

Offline

#11 21.12.2018 08:37:13

stefanhusmann
Moderator

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

#12 21.12.2018 12:22:32

hcjl
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

Online

#13 21.12.2018 13:37:06

Hanisch
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

Beitrag geändert von Hanisch (21.12.2018 14:55:43)

Offline

#14 22.12.2018 00:49:10

Wei1nah2
Gast

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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!

#15 22.12.2018 00:58:45

Hanisch
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

Offline

#16 22.12.2018 01:10:28

Wei1nah2
Gast

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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.

#17 22.12.2018 12:10:44

Hanisch
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

Beitrag geändert von Hanisch (22.12.2018 12:18:25)

Offline

#18 22.12.2018 12:37:24

Wei1nah2
Gast

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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.

#19 22.12.2018 13:06:40

drcux
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

#20 22.12.2018 13:16:39

Wei1nah2
Gast

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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.

#21 23.12.2018 14:24:20

Hanisch
Mitglied

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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

Offline

#22 23.12.2018 14:49:56

Wei1nah2
Gast

Re: [Gelöst]mount(2) Systemaufruf ist fehlgeschlagen

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.

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums