No write access in a 9p/virtfs shared folder
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Invalid
|
Undecided
|
Unassigned | ||
qemu-kvm (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Ubuntu version: Ubuntu 12.04 LTS
Kernel: 3.2.0-25-generic
Version of qemu-kvm: 1.0+noroms-
I have created an shared folder for an virtual machine which is managed by libvirt.
<filesystem type='mount' accessmode=
<source dir='/storage/
<target dir='data'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</filesystem>
I mounted it in the virtual machine with this command: mount -t 9p -o trans=virtio,
The filesystem permissions of all files an folders in the shared folder are set to 777. I expected that I have the full permissions also in the virtual machine.
Regardless of the permissions on the filesystem I cannot write or create files and folders in the virtual machine. The original filesystem (/storage) is XFS.
In another shared folder (similar config in libvirt) which is originally NTFS I have no problems.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: qemu-kvm 1.0+noroms-
ProcVersionSign
Uname: Linux 3.2.0-25-generic x86_64
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
Date: Wed Jun 27 20:15:20 2012
InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Beta amd64 (20120409)
MachineType: To be filled by O.E.M. To be filled by O.E.M.
ProcEnviron:
TERM=xterm
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: qemu-kvm
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/18/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1208
dmi.board.
dmi.board.name: M5A99X EVO
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: To be filled by O.E.M.
dmi.product.
dmi.sys.vendor: To be filled by O.E.M.
Thanks for reporting this bug. Could you check your /var/log/syslog for apparmor messages relating to libvirt accessing /data? The command
sudo grep DENIED /var/log/syslog | grep libvirt
should return interesting results.