1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
files: 0.986
device: 0.984
graphic: 0.983
user-level: 0.963
semantic: 0.957
ppc: 0.953
permissions: 0.947
virtual: 0.946
mistranslation: 0.944
PID: 0.941
performance: 0.933
vnc: 0.923
register: 0.921
debug: 0.921
architecture: 0.878
socket: 0.855
network: 0.843
boot: 0.825
arm: 0.821
peripherals: 0.789
risc-v: 0.771
VMM: 0.769
hypervisor: 0.758
kernel: 0.752
assembly: 0.740
TCG: 0.701
x86: 0.218
i386: 0.197
KVM: 0.055
virtfs: mapped-xattr on mount point
With
-virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2"
in the qemu command line,
shared2 on /mnt/testbis type 9p (rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144)
in the guest mount points, and
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
in the host mount points (with CONFIG_TMPFS_XATTR=y according to zgrep /proc/config.gz), running qemu as user "vm-test", trying to "touch a" in /mnt/testbis on the VM fails with "Operation not supported". In addition, no file or directory actually present in the host's /tmp can be seen in the guest's /mnt/testbis.
When trying to replace "/tmp" with "/tmp/aaa" on the host, with /tmp/aaa owned by root:root, still running qemu as vm-test, trying to run "ls" in the guest's /mnt/testbis fails with the weird "ls: reading directory '.': Cannot allocate memory", while the directory is empty.
After a "chown vm-test /tmp/aaa", the guest can list the files (despite the permissions already allowing it to do so before), but still not write new files: "cannot touch 'b': Operation not supported".
Do you have a pointer as to what is happening?
PS: complete setup is running all this inside a qemu VM that I use for testing, I guess it shouldn't matter but saying it just in case
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
Independent of the planned tracker transition: this issue would require more information by original reporter anyway.
From the information provided so far, I cannot reproduce this problem, and the error messages don't look like common misconfigurations on host side like wrong permissions, AppArmor policies or something like that. Especially the error message "Cannnot allocate memory" looks weird to me. So I think there should at least be more details about the host system this was deployed on.
Hmm… so this dates back quite long ago unfortunately, I had basically forgotten about this bug report as I had opened it while just experimenting with qemu.
To the best of my recollection, this was happening with a NixOS, either 16.09, 17.03 or unstable, at an update that was probably within 0-2 months of the time I made the bug report.
Now, I guess the best may be to just close as can't reproduce, as I no longer have the code originally used to trigger the issue anyway?
Either way, thank you for your feedback!
Thanks for your answer! ... since this is not reproducible anymore, I'm closing the ticket now.
|