Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: For no clear reson a part of systemd runs and complains about a weird gvfs directory that is made by the distro. I do not expect to see my logs littered by non-errors as is teh case with fedora in its recent incarnations. Please fix! Version-Release number of selected component (if applicable): systemd-44-21.fc17.x86_64 How reproducible: Run Fedora 17. Use it. Actual results: systemd-tmpfiles[18919]: stat(/run/user/udo/gvfs) failed: Permission denied Expected results: no such log entries in messages file Additional info:
Hmm, this is caused by FUSE which disallows access to shares served by unprivileged code even to privileged code, in order to ensure that unprivileged code cannot use this to deadlock privileged code. Not sure what we can do about this. Just suppressing the error sounds problematic. Without stat()ing the inode we unfortunately can't determine its type either, and not look it up in /proc/self/mountinfo we'd have to use name_to_handle() which doesn't really work with no access either. Not sure what thebest way to handle this is.
I don't know of a perfect solution either, but looking it up in /proc/self/mountinfo by directory name could be good enough.
You mean looking it up by path in /proc/self/mountinfo? I guess that would be good enough, after all this is simply about suppressing a message, and has little effect on the control flow otherwise.
*** Bug 922325 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Still a problem in F19. Journalctl includes a priority 3 message: systemd-tmpfiles[2733]: stat(/run/user/1000/gvfs) failed: Permission denied Kernel : 3.10.7-200.fc19.x86_64 systemd.x86_64: 204-9.fc19 I expect any log messages thrown at priority 3 to be actionable.
Same here, F19 : systemd-tmpfiles[4505]: stat(/run/user/1000/gvfs) failed: Permission denied Kernel : 3.10.9-200.fc19.x86_64 systemd 204
hi, there is still the same issue: cat /var/log/messages | grep denied Oct 13 09:36:25 masox systemd-tmpfiles[21940]: stat(/run/user/1002/gvfs) failed: Permission denied Oct 14 09:36:25 masox systemd-tmpfiles[6280]: stat(/run/user/1002/gvfs) failed: Permission denied # rpm -q systemd systemd-204-16.fc19.x86_64
Moving this against the correct component ( gvfs ) component since this has nothing do do with systemd GVFS crew did this go [¹] any further or something else that tries to fix the "design" flaw in gvfs ? 1.https://bugzilla.gnome.org/review?bug=560658&attachment=235417
Nah, this is more a side effect of FUSE, since fuse means file systems run by unprivileged users are not accessible to root. We should probably automatically detect this and skip over the file systems in questions. Reassigning back to systemd.
-EACCES failures are only printed at the debug level now
systemd-204-17.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/systemd-204-17.fc19
Package systemd-204-17.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-204-17.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-19730/systemd-204-17.fc19 then log in and leave karma (feedback).
systemd-204-17.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
systemd-201-2.fc18.9 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.9
Package systemd-201-2.fc18.9: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.9' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-20267/systemd-201-2.fc18.9 then log in and leave karma (feedback).
systemd-201-2.fc18.9 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.