Ein Ubuntu Server 14.04-Host hostet einen Ubuntu Server 14.04-Gast über libvirt / qemu-kvm. Das System läuft einwandfrei, aber als Gast habe ich Probleme beim Schreiben in einen freigegebenen Ordner ( <filesystem>), die mich verrückt machen. Beide Maschinen sind relative Vanille-Installationen.

Ich habe den angegebenen Ordner folgendermaßen angehängt:

[host] $ virsh edit guest-vm-name
# ...
<filesystem type='mount' accessmode='mapped'>
  <source dir='/data'/>
  <target dir='/data'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</filesystem>
# ...

Vom Gast aus mounte ich das Dateisystem wie folgt:

[guest] $ sudo -u www-data mkdir /tmp/mnt
[guest] $ sudo mount -t 9p -otrans=virtio,rw,version=9p2000.L /data /tmp/mnt

Ich benutze den www-dataBenutzer, da dies später der efftive-Benutzer sein wird und Gruppen- und Benutzer-IDs übereinstimmen müssen, wenn p9 verwendet wird. Das bedeutet auch, dass auf dem Host / data (das ist ext4-Partition, LVM auf RAID übrigens) so aussieht

[host] $ ls -lha /data
[host] $ drwxrwxr-x  4 www-data www-data 4.0K Nov 11 08:34 .
[host] $ drwxr-xr-x 24 root     root     4.0K Nov  7 16:58 ..
[host] $ drwxr-xr-x  2 www-data www-data 4.0K Nov 11 08:34 jail
# ...

Wenn ich im Gast versuche, auf etwas im freigegebenen Dateisystem zu schreiben, erhalte ich Berechtigungsfehler (unabhängig vom verwendeten Benutzer):

[guest] $ sudo -u www-data touch /tmp/mnt/jail/letmeout
touch: cannot touch ‘/tmp/mnt/jail/letmeout’: Permission denied

Ich kann aber Dateien lesen

[guest] $ cat /tmp/mnt/jail/throughthewindow
Great Weather!

Ich habe verschiedene Dinge ausprobiert, insbesondere:

• Apparmor Service gestoppt und aa-Beschwerde angerufen (ich hoffe, das war effektiv)
• Setzen Sie die Sicherheit auf keine in /etc/libvirt/qemu.conf
• Setzen Sie Benutzer und Gruppe auf root in /etc/libvirt/qemu.conf

/ var / log / syslog und dmesg zeigen nichts Verdächtiges an.

Irgendwelche Hinweise?! Vielen Dank.

Ich weiß, dass dies ein alter Thread ist, aber ich bin gerade auf ein ähnliches Problem gestoßen und habe eine Lösung gefunden, die zumindest teilweise funktioniert .

Ich habe auch die Benutzer- und Gruppenwerte in /etc/libvirt/qemu.confzu root , wie Sie haben.
Ich habe aber auch die dynamic_ownershipEinstellung geändert , weil die Beschreibung vielversprechend klang:

# Ob libvirt den Dateibesitz dynamisch ändern soll,
# um dem oben konfigurierten Benutzer / der oben konfigurierten Gruppe zu entsprechen. Der Standardwert ist 1.
# Auf 0 setzen, um Änderungen des Dateibesitzes zu deaktivieren.

Mein Setup ist:

• Gastgeber: Debian 8 (Jessie)
• Gast: Debian 8 (Jessie)
• Der freigegebene Ordner auf dem Host gehört zu root
• Der lokale Benutzer mit der ID 1000 ist Mitglied der Gruppe libvirt(möglicherweise wichtig).
• Der Mount-Punkt auf dem guest ( /mnt/data) gehört dem Benutzer 1000 ("alexander").

Ich kann jetzt schreiben schließlich Dateien im montierten freigegebenen Ordnern mit beiden Wurzeln (0) und Alexander (1000). (vorher durfte nur root hier Dateien schreiben)

Das Setzen dynamic_ownershipauf 0 muss im "zugeordneten" Zugriffsmodus erfolgen.

Hier sind einige weitere Informationen zu meinem Setup:

/etc/libvirt/qemu.conf:

user = "root"
group = "root"
dynamic_ownership = 0

Dateisystem (virsh edit):

<!-- ... -->
    <filesystem type='mount' accessmode='mapped'>
      <source dir='/share/vm.localdomain/owncloud_data'/>
      <target dir='/data'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </filesystem>
<!-- ... -->

Wirt:

ls -al /share/vm.localdomain/owncloud_data/
total 8
drwxr-xr-x 2 root      root      4096 Sep  8 00:15 .
drwxr-xr-x 7 root      root      4096 Sep  8 00:10 ..

fstab auf Gast:

/data  /mnt/data/  9p  trans=virtio  0  0

Gast:

root@debian:~# cd /mnt/data
root@debian:/mnt/data# touch touched_by_root
root@debian:/mnt/data# su - alexander
alexander@debian:~$ cd /mnt/data
alexander@debian:/mnt/data$ touch touched_by_user
alexander@debian:/mnt/data$ ls -al
total 16
drwxr-xr-x 2 alexander alexander 4096 Sep  8 00:30 .
drwxr-xr-x 6 root      root      4096 Sep  7 18:13 ..
-rw-r--r-- 1 root      root         0 Sep  8 00:30 touched_by_root
-rw-r--r-- 1 alexander alexander    0 Sep  8 00:30 touched_by_user

zurück auf Host:

root@Host /share/vm.localdomain # ls -al /share/vm.localdomain/owncloud_data/
total 16
drwxr-xr-x 2 root      root         4096 Sep  8 00:30 .
drwxr-xr-x 7 root      root         4096 Sep  8 00:10 ..
-rw------- 1 root      libvirt-qemu    0 Sep  8 00:30 touched_by_root
-rw------- 1 root      libvirt-qemu    0 Sep  8 00:30 touched_by_user

Fazit

Das Seltsame ist, dass diese beiden Dateien auf dem Gast unterschiedlichen Benutzern gehören (root vs. alexander), während auf dem Host beide Dateien demselben Benutzer gehören (root: libvirt-qemu). : -O
Ich weiß nicht genau, wie diese Magie funktioniert , aber anscheinend schon.

Hoffe das hilft,
Alexander

@ Alexander gab eine tolle Antwort. Ich habe nicht alles getan, was er getan hat, aber das habe ich getan, damit die gleichen Benutzerrechte im 9p-Dateisystem in beide Richtungen funktionieren. (Auf diese Weise soll nur 9p ohne Sicherheitsprobleme in beide Richtungen zum Laufen gebracht werden. Für mehr Sicherheit benötigen Sie eine andere Methode oder andere Einstellungen.)

HOST (Bestellung ist unwichtig)

• Ich habe meinen Hostbenutzer der folgenden Gruppe hinzugefügt: < kvm > (Ich bin auch Mitglied von < libvirtd >). Dieser Schritt ist möglicherweise nicht erforderlich, weil:

• In der Datei /etc/libvirt/qemu.conf können Sie den Benutzer und die Gruppe ändern, mit denen sich alle Ihre VMs authentifizieren und ausführen.

( Dies ist eine mächtige kleine Änderung, und die Auswirkungen müssen herausgearbeitet werden, wenn Sie versuchen, dies auf so etwas wie einem Produktionsserver zu erreichen. )

user = "billy"    #### No, my name isn't billy, but it's cute. 
                  #### Alternatively you can declare your <uid>, like
                  ## user = "+1000" ####        << That's what I did.
                  #### (They tell you everything you need to know about
                  #### this stuff inside /etc/libvirt/qemu.conf)
group = "billy"
dynamic_ownership = 1

(Mit der obigen Änderung wird der Host der virtuellen Maschine angewiesen, alle libvirt-Cross-VM-Anforderungen für alle von Ihnen ausgeführten Gast-VMs in den von Ihnen festgelegten < Benutzer > zu konvertieren , einschließlich der Gast-VM < Stamm >. * Beachten Sie erneut, dass dies der Fall ist ist eine systemweite Einstellung in Bezug auf libvirt und im weiteren Sinne qemu, wenn libvirt Ihre einzige qemu- Schnittstelle ist.)

• Richten Sie Ihr Hosting so ein, wie es in diesem hervorragenden offiziellen Dokument https://www.linux-kvm.org/page/9p_virtio zu finden ist

("Squash" verweist übrigens auf ein 9p-Sicherheitsmodell. Es bedeutet "keine" und ist die zulässigste Einstellung für diesen Kontext.)

GAST

• Mounten Sie in der Gast-VM die 9p-Freigabe mit < Root > -Rechten, die sich ebenfalls am Ende des Dokuments https://www.linux-kvm.org/page/9p_virtio befinden

(Ich habe auch eine Option hinzugefügt, wie im folgenden Dokument erläutert.) Mein Mount-Befehl lautet:

mount -t 9p -o trans=virtio,access=any,version=9p2000.L /hostshare /tmp/host_files

Wenn Sie nach dem Einrichten keine Berechtigung zum Schreiben auf die Freigabe oder nur eine eingeschränkte Berechtigung haben, sollte der hervorragende Vorschlag von @randomoceans Antwort hilfreich sein. Das heißt, lassen Sie < stamm > einen Ordner unter der Freigabe erstellen und chmod 777auf diesen festlegen .

- Noch mehr Informationen: https://wiki.qemu.org/Documentation/9psetup

Ich hatte auch dieses Problem, habe einen Ordner mit dem Namen /home/user/sharedauf dem Host erstellt und dann den Ordner mit virt-manager hinzugefügt und als 9p virtio auf der qemu VM bereitgestellt.

Ich habe die Einstellungen in /etc/apparmor.d/libvirt überprüft und es enthält Einträge für das neue /home/user/shared,und ich habe festgestellt, dass es nur die rBerechtigung für hat, /home/user/sharedaber rwfür alle Dateien in /home/user/shared/. Ich habe versucht, aw für Schreibberechtigungen hinzuzufügen, aber das schien nicht gespeichert zu werden, also bin ich in den Host gegangen /home/user/sharedund habe ein Unterverzeichnis erstellt und ein chmod 777 für dieses Unterverzeichnis erstellt. Das hat funktioniert und die Gast-VM konnte alle Erstellungs- und Bearbeitungsdateien an den su-Direktor schreiben.

tldr: Erstellen Sie ein Unterverzeichnis im freigegebenen Ordner mit 777 Berechtigungen und prüfen Sie, ob Sie darauf schreiben können.