Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#32715 - [gvfs] systemd-tmpfiles gets "permission denied" on /run/user/<uid>/gvfs

Attached to Project: Arch Linux
Opened by René Herman (rene) - Friday, 16 November 2012, 20:00 GMT
Last edited by Jan de Groot (JGC) - Tuesday, 02 April 2013, 22:18 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No



Minor, and I believe known, but systemd-tmpfiles (the cleanup of temporary directories) spits an error to the system log upon not being able to access /run/user/<uid>/gvfs.

As the user in question, this directory show itself to have permissions:

$ ls -ld /run/user/<uid>/gvfs/
dr-x------ 2 <user> users 0 Nov 16 18:40 /run/user/<uid>/gvfs/

whereas as root, we obtain:

# ls -ld /run/user/<uid>/gvfs/
ls: cannot access /run/user/<uid>/gvfs/: Permission denied

While quite, erm, interesting to see root having fewer permissions than my user, I believe this is not in fact unexpected. Just built up a new arch system with systemd for the first time though and thought I'd report this anyway. It's now in scary-red in journalctl after all!

systemd: 195-2
gvfs: 1.14.2-1

Nov 16 18:55:17 e600 systemd[1]: Starting Cleanup of Temporary Directories...
Nov 16 18:55:17 e600 systemd-tmpfiles[637]: stat(/run/user/<uid>/gvfs) failed: Permission denied
Nov 16 18:55:17 e600 systemd[1]: Started Cleanup of Temporary Directories.
This task depends upon

Closed by  Jan de Groot (JGC)
Tuesday, 02 April 2013, 22:18 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in GNOME 3.8.
Comment by Jan de Groot (JGC) - Wednesday, 28 November 2012, 10:43 GMT
Yes, this is well known and a limitation in fuse. See for a discussion about this. It's possible to give root access to these directories somehow, but you don't want any system tool to traverse fuse mounts done by users, so this is probably a wontfix.
Comment by René Herman (rene) - Wednesday, 28 November 2012, 12:18 GMT
Ah, thanks for the link. Comment #25 there seems quite relevant, but yes, I see that this is then something which will at least for now only be helped by a workaround -- for those who care.

I have just installed the following as /etc/tmpfiles.d/gvfs.conf:

rene@e600 ~]$ cat /etc/tmpfiles.d/gvfs.conf
# The FUSE mount(s) /run/user/*/gvfs are inaccessible to root and thereby
# cause systemd-tmpfiles --clean to spit an error to the system log upon
# it trying to stat these directories.
# While this FUSE behaviour might be considered a FUSE problem, solve this
# for now by telling systemd-tmpfiles to just stay out of /run/user/*.
# Note that more specifically telling it to stay out of /run/user/*/gvfs
# does not help since it'll still stat those directories when traversing
# /run/user/*.

x /run/user/*

As this mentions, we can't tell it to just stay away from the gvfs directories specifically, since it's traversing their parents which is the problem, which means that calling this "gvfs.conf" is perhaps a little besides the point. Still, it's gvfs that causes the error in a most direct sense I guess, and if you feel that this error message IS in fact an issue, it might be an idea to have the arch gvfs package install this as /usr/lib/tmpfiles.d/gvfs.conf (note also, by the way, that "x /run/user" doesn't work, it needs to be "/run/user/*")

Given that systemd is a new-ish addition to arch, I guess more users are going to be scouring the logs to feel confident that they did things right as as such, it may have some merit.

There's also a thread here, I notice:

I'll post a link to this report there as well.