systemd-tmpfiles: stat(/run/user/1000/gvfs) failed: Permission denied
Can anyone tell me why this is in my journalctl ? Sometimes many times, depending on the application I use,
other times, once or twice in a 5 hour uptime.
From the very limited information you provided, it would seem as though it is trying to create /run/user/1000/gvfs but fails due to permissions issues. Does gvfs work?
The directory is created on boot.
I am using XFCE4 with the following gvfs-1.12.3-3
~]$ stat /run/user/1000/gvfs File: ‘/run/user/1000/gvfs’ Size: 0 Blocks: 0 IO Block: 4096 directory Device: 1fh/31d Inode: 1 Links: 2 Access: (0500/dr-x------) Uid: ( 1000/ kilzool) Gid: ( 100/ users) Access: 2012-08-19 14:06:46.000000000 -0400 Modify: 2012-08-19 14:06:46.000000000 -0400 Change: 2012-08-19 14:06:46.000000000 -0400 Birth: -
As per your question does gvfs work, I assume it does. How does one tell?
Last edited by Kilzool (2012-08-19 19:00:39)
What info need to be provided?
I have the same issue.
Last edited by Kilzool (2012-08-21 14:16:10)
gvfs is what enables your disks to automount within a file manager. So open nautilus, pcmanfm, or whatever you use and see if it allows you to mount an external drive or other partition that is not part of your filesystem.
In my case flash drives and an external HDD work fine.
Yeah, I am unsure if it is all working correctly. I installed gvfs and rebooted to see what is going on. /run/user/1000/gvfs is a directory. So presumable systemd-tmpfiles wants to write something in there. What are the permissions of that directory? also what does the following yeild?
grep /run/user/1000/gvfs /lib/tmpfiles.d/*
You may also want to grep the same thing in /etc/tmpfiles.d, but I imagine you probably have not created any of your own tmpfiles.
grep /run/user/1000/gvfs /lib/tmpfiles.d/*
gives me nothing and yes i haven't made any tmpfiles of my own
Last edited by 89c51 (2012-08-21 16:05:56)
to be honest, then I really have no idea why it systemd-tmpfiles would be trying to stat teh gvfs directory. if it is not causing any problems within your system, I would probably not be too increibly concerned. did you try uninstalling and/or reinstalling gvfs?
Well not yet. I do remember gvfs at one point had a directory in my ~home directory.
I deleted that directory and it has not since been created (that was like a month ago).
And since systemd -- it has, I guess, created it as /run/user/1000/gvfs (1000 uid being the first user, which is me).
Wish we could get more input on this.
same errur here. The wierd thing is the permissions of the dir....
d????????? ? ? ? ? ? gvfs
Wow that is funky... I sort of remember gvfs mounting in ~/.gvfs but it has been a while, so I am not entirely certain about that. Actually, I just checked, and that directory still exists in my home folder. I guess my home folder needs some spring (or late summer) cleaning.
same here with systemd. From log file:
localhost systemd-tmpfiles: stat(/run/user/1000/gvfs) failed: Permission denied [gabx@magnolia:1000]$ ls -al ... dr-x------ 2 gabx users 0 Aug 31 21:32 gvfs [gabx@magnolia:1000]$ chmod -R u+w gvfs [gabx@magnolia:1000]$ ls -al ... dr-x------ 2 gabx users 0 Aug 31 21:32 gvfs
As you can see, can't even change permission for user gabx to write the directory.
[gabx@magnolia:~]$ systemctl status systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; enabled) Active: active (exited) since Fri, 31 Aug 2012 21:32:00 +0200; 46min ago Docs: man:tmpfiles.d(5) Process: 353 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/systemd-tmpfiles-setup.service [gabx@magnolia:~]$ sudo systemctl status systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; enabled) Active: active (exited) since Fri, 31 Aug 2012 21:32:00 +0200; 47min ago Docs: man:tmpfiles.d(5) Process: 353 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/systemd-tmpfiles-setup.service
Following the above status, it seems everything is OK, so I am not sure this permission denied is really an issue.
Last edited by gabx (2012-08-31 23:31:01)
Seems to me like a know bug https://bugs.launchpad.net/gvfs/+bug/225361
Shouldn't the folders just be excluded from the systemd-tmpfiles-clean.service routine? Doesn't look to me like the gconf folders should be rm'able by root and I'm not sure if there are plans to ever make them stat'able... so...
Is this a case for a "feature request" at [wherever this service file comes from]?
Or am I misinterpreting what the problem is?
Last edited by whoops (2012-11-25 12:42:44)
I agree with whoops#16, but it is a bit unfortunate that just excluding the /run/user/*/gvfs directories doesn't help, since it's traversing /run/user/* itself which is the problem. Clearly, just telling the bloody thing to stay the <bleep> out of all of /run/user/* DOES work...
There's also a bug-report here: https://bugs.archlinux.org/task/32715
I still have this bug:
[fabio@muletto ~]$ sudo systemd-tmpfiles --clean
stat(/run/user/1000/gvfs) failed: Permission denied
Just now noticed that someone closed the bug-report from #17 as "fixed" (and I see you requested a reopen). As far as I'm aware, this was "planned" to in fact never be fixed, since the problem is fuse breaking UNIX semantics in a serious way -- and it having done so for ever, which no doubt means they believe they have a good reason to do so.
If I were you, I'd stop caring, and install that /etc/tmpfiles.d/gvfs.conf from the report...