You are not logged in.
systemd-tmpfiles[2346]: 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.
Offline
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?
Offline
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)
Offline
What info need to be provided?
I have the same issue.
Offline
[Deleted]
Last edited by Kilzool (2012-08-21 14:16:10)
Offline
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.
Offline
In my case flash drives and an external HDD work fine.
Offline
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.
Offline
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)
Offline
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?
Offline
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.
Offline
same errur here. The wierd thing is the permissions of the dir....
d????????? ? ? ? ? ? gvfs
Offline
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.
Offline
same here with systemd. From log file:
localhost systemd-tmpfiles[12898]: 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.
EDIT:
[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)
Offline
Seems to me like a know bug https://bugs.launchpad.net/gvfs/+bug/225361
Offline
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)
Offline
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
Offline
I still have this bug:
[fabio@muletto ~]$ sudo systemd-tmpfiles --clean
stat(/run/user/1000/gvfs) failed: Permission denied
Offline
@ fabioamd87:
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...
Offline