[Bug 1673957] Re: virtfs: mapped-xattr on mount point
Thanks for your answer! ... since this is not reproducible anymore, I'm closing the ticket now. ** Changed in: qemu Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1673957 Title: virtfs: mapped-xattr on mount point Status in QEMU: Won't Fix Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1673957/+subscriptions
[Bug 1673957] Re: virtfs: mapped-xattr on mount point
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! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1673957 Title: virtfs: mapped-xattr on mount point Status in QEMU: Incomplete Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1673957/+subscriptions
[Bug 1673957] Re: virtfs: mapped-xattr on mount point
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. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1673957 Title: virtfs: mapped-xattr on mount point Status in QEMU: Incomplete Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1673957/+subscriptions
[Bug 1673957] Re: virtfs: mapped-xattr on mount point
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. ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1673957 Title: virtfs: mapped-xattr on mount point Status in QEMU: Incomplete Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1673957/+subscriptions
