Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Start a virtiofsd with the current user, but the shared folder belongs to another group and the curent user belongs to that group as well, try to create a file in the shared dir but failed.
Version-Release number of selected component (if applicable):
virtio-win-prewhql-0.1-228
qemu-kvm-7.1.0-3.el9.x86_64
5.14.0-178.el9.x86_64
edk2-ovmf-20220826gitba0e0e4c6a-1.el9.noarch
How reproducible:
100%
Steps to Reproduce:
1.Add two users on host
# useradd u1
# useradd u2
2.Change permission of u1 home directory
# chmod -R 777 u1
u1]# ll
total 8
-rwxrwx---. 1 u1 u1 2730 Nov 14 22:53 boot.sh
srwxrwx---. 1 u1 u1 0 Nov 14 22:52 sock1
-rwxrwx---. 1 u1 u1 7 Nov 14 22:52 sock1.pid
drwxrwx---. 3 u1 u1 41 Nov 14 22:55 test
3.Change user u2's supplementary group to u1
# usermod -G u1 u2
# id u2
uid=1002(u2) gid=1002(u2) groups=1002(u2),1001(u1)
4. switch to u2 and start virtiofsd
[root@dell-per440-06 u1]# su u2
[u2@dell-per440-06 u1]$ /usr/libexec/virtiofsd -o source=test --socket-path=sock1
5. start virtiofsd and ws2022 vm with user u2.
[u2@dell-per440-06 u1]$ /usr/libexec/virtiofsd -o source=test --socket-path=sock1
6. start virtiofs service in guest and get z: volume
7. try to create a file in guest
Actual results:
Failed and it shows "File too Large" .....(see attachment)
Expected results:
success to create file
Additional info:
1. Linux guest has different result in step7.
Be able to create file in shared dir.
# ll
-rw-r--r--. 1 u2 u1 5 Nov 15 2022 file.txt
2. Only creating files/folders failed, while modifying files worked.
Comment 4Yvugenfi@redhat.com
2023-01-19 09:15:00 UTC
Added new parameters named OverflowUid and OverflowGid, they are always parsed from the registry. Normally, these parameters only affect if the host daemon is running inside a Linux user namespace. They denote UID and GID perceived as nobody on the host, so they should be in sync with corresponding host values. If the service finds out shared folder root owner UID/GID becomes nobody, it will try previous UID/GID as owner for new files and folders. They assumed to be 65534 if no such parameters are found in the registry.