Bug 880709

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.