df -h permission denied error

[Robert Kulagowski]

Running "df -h" from the cli as a normal user returns:

Filesystem Size Used Avail Use% Mounted on
/dev/md0 37G 6.6G 29G 19% /
udev 796M 8.0K 796M 1% /dev
tmpfs 322M 888K 321M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 805M 92K 805M 1% /run/shm
/dev/sda3 1.8T 265G 1.6T 15% /mnt/d1
/dev/sdb3 1.8T 1.7T 102G 95% /mnt/d2
/dev/sdc3 893G 33M 893G 1% /mnt/d3
df: `/var/lib/lightdm/.gvfs': Permission denied
$

running with "su"

$ sudo df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 37G 6.6G 29G 19% /
udev 796M 8.0K 796M 1% /dev
tmpfs 322M 888K 321M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 805M 92K 805M 1% /run/shm
/dev/sda3 1.8T 265G 1.6T 15% /mnt/d1
/dev/sdb3 1.8T 1.7T 102G 95% /mnt/d2
/dev/sdc3 893G 33M 893G 1% /mnt/d3
$

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: bash 4.2-0ubuntu4
ProcVersionSignature: Ubuntu 3.0.0-10.16-server 3.0.4
Uname: Linux 3.0.0-10-server x86_64
ApportVersion: 1.23-0ubuntu2
Architecture: amd64
Date: Tue Oct 4 14:17:28 2011
InstallationMedia: Ubuntu-Server 11.04 "Natty Narwhal" - Release amd64 (20110426)
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
SourcePackage: bash
UpgradeStatus: Upgraded to oneiric on 2011-09-05 (29 days ago)

[Luke Scharf (lukescharf)]

This is how Unix systems are supposed to behave. The ~lightdm/.gvfs filesystem is a private FUSE-mounted filesystem that belongs to the lightdm user, so a normal user shouldn't be able to access it. The same thing would happen if you had a GVFS filesystem open as yourself and another user (who was were logged in to the machine via ssh of via the switch-user feature) ran df -h.

I certainly see why this text being dumped to stderr on a common command like df -h feels like an error, though.

This behavior runs deep into the design of the Linux (and all Unix) kernel, but I'd be interested in any ideas you have about how to modify the behavior to be more suitable.

[Robert Kulagowski (rkulagow-gmail)]

On Wed, Oct 5, 2011 at 5:09 PM, Luke Scharf <email address hidden> wrote:
> This is how Unix systems are supposed to behave.  The ~lightdm/.gvfs
> filesystem is a private FUSE-mounted filesystem that belongs to the
> lightdm user, so a normal user shouldn't be able to access it.  The same
> thing would happen if you had a GVFS filesystem open as yourself and
> another user (who was were logged in to the machine via ssh of via the
> switch-user feature) ran df -h.
>
> I certainly see why this text being dumped to stderr on a common command
> like df -h feels like an error, though.
>
> This behavior runs deep into the design of the Linux (and all Unix)
> kernel, but I'd be interested in any ideas you have about how to modify
> the behavior to be more suitable.
>
> ** Changed in: bash (Ubuntu)
>       Status: New => Opinion

I understand how permissions work - it's just odd to run into that as
a standard user. "Principle of least surprise", since it wasn't doing
it on my other Ubuntu systems. In any case, I've updated and the
error (or the root cause) appears to be gone now.

[Luke Scharf (lukescharf)]

I was trying to figure out why lightdm would be fuse-mounting .gvfs. I'm glad to hear it's fixed!

[falstaff (falstaff)]

This still happens to me as soon as an User is logged in. It has a nasty side effect in munin, which tries to get harddisk usage using df. df's return value in that case is not 0, so the result is not being processed. While it's possible to fix that in munin, its nevertheless a bit strange that df return's that error and therfore return 1 as error value.

$ df -h
....
df: „/var/lib/lightdm/.gvfs“: Permission denied
$ echo $?
1

[Bryan Batten (bryanbatten)]

My experience is that things are OK if I run the df command from a local terminal window as a standard user or as root.

However, if I ssh in from another machine, while I can run the df command without error if I do a sudo -s first, I still get the error if I just try it as a normal user. As of (maybe) two weeks ago, the problem did not occur at all.

Thanks,

[Bryan Batten (bryanbatten)]

BTW I have the latest 11.10 patches - as of this AM

[Antti Hätinen (antti-hatinen)]

For me this hinders the nagios usage, since check_disk fails with error since it can't read status of /var/lib/lightdm/.gvfs . Also, when I removed then lightdm package, the .gvfs file doesn't disappear and I can't find a way to delete it.

[Mat Ludlam (matludlam)]

So to summarise I have exactly the same problem when I use ssh to connect to Ubuntu 11.10 with all patches up to and including 8th of Feb 2012.

Output from "uname -a" is

Linux dev4 3.0.0-15-generic #26-Ubuntu SMP Fri Jan 20 17:23:00 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Generally this error occurs when I am a normal user but does not show if I am root. I also believe that I have seen the problem when running "sudo df" but I cannot 100% confirm this.

If the error appears then the return code is set to 1.

I also believe that this is a reasonably recent behavioural change on my system. I have added a lot of packages recently so one could have triggered this.

[John Sopko (sopko)]

I am seeing this in precise 12.04, latest patches, some machines have the issue, others do not:

% lsb_release -dcr
Description: Ubuntu 12.04 LTS
Release: 12.04
Codename: precise

% df -hl
df: `/var/lib/lightdm/.gvfs': Permission denied
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sdavg-root 9.3G 3.1G 5.8G 35% /
udev 489M 4.0K 489M 1% /dev
tmpfs 199M 804K 198M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 496M 144K 496M 1% /run/shm
/dev/mapper/sdavg-backup 20G 416M 18G 3% /backup
/dev/sda1 184M 30M 146M 17% /boot

[Garen (garenp)]

This is not fixed - I just encountered this after upgrading from 10.04 to 12.04.

[John Sopko (sopko)]

If someone is logged into the desktop, gvfs mounts in there home dir, and df works if you ssh login as another user and do a df. The problem I am seeing is when no one is logged in and /var/lib/lightdm/.gvfs is mounted. For example:

No one logged into the desktop:

$ df
df: `/var/lib/lightdm/.gvfs': Permission denied
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/sdavg-root 9733688 3411164 5834284 37% /
udev 495080 4 495076 1% /dev
tmpfs 201656 808 200848 1% /run
none 5120 0 5120 0% /run/lock
none 504140 152 503988 1% /run/shm
/dev/mapper/sdavg-backup 19932248 425728 18506688 3% /backup
/dev/sda1 188403 30626 148049 18% /boot

The mount command shows the mount:

$ mount | grep gvfs
gvfs-fuse-daemon on /var/lib/lightdm/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=lightdm)

If another users is logged into the system mount shows:

mount | grep gvfs
gvfs-fuse-daemon on /home/sopkol/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=sopkol)

and df works:

$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/sdavg-root 9733688 3411196 5834252 37% /
udev 495080 4 495076 1% /dev
tmpfs 201656 808 200848 1% /run
none 5120 0 5120 0% /run/lock
none 504140 152 503988 1% /run/shm
/dev/mapper/sdavg-backup 19932248 425728 18506688 3% /backup
/dev/sda1 188403 30626 148049 18% /boot

[John Sopko (sopko)]

Another observation. When no one is logged in and /var/lib/lightdm is mounted the directory permissions do not allow other access:

% ls -ld /var/lib/lightdm
drwxr-x--- 9 lightdm lightdm 4096 May 6 09:50 /var/lib/lightdm

If someone is logged into the desktop gui the gvfs directory permissions are set to whatever the users home directory is set to:

% ls -ld /home/sopkol
drwxr-xr-x 23 sopkol sopkol 4096 May 8 15:54 /home/sopkol

So if you can read the directory mount df does not complain permission denied.

If you chmod on /var/lib/lightdm so you can read the dir the problem goes away. Don't know if that is a security issue:

% chmod 755 ld /var/lib/lightdm

and df will not complain.

I did a reboot and the permissions did not change and it still worked:

% mount | grep gvfs
gvfs-fuse-daemon on /var/lib/lightdm/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=lightdm)

 |% ls -ld /var/lib/lightdm
drwxr-xr-x 9 lightdm lightdm 4096 May 8 16:01 /var/lib/lightdm/

 |% df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/sdavg-root 9733688 3411316 5834132 37% /
udev 495080 4 495076 1% /dev
tmpfs 201656 804 200852 1% /run
none 5120 0 5120 0% /run/lock
none 504140 144 503996 1% /run/shm
/dev/mapper/sdavg-backup 19932248 425728 18506688 3% /backup
/dev/sda1 188403 30626 148049 18% /boot

[Nico Schlömer (nschloe)]

This bug also affects anyone trying get disk usage statistics using Cacti.
The script executed by Cacti is

$ perl /usr/share/cacti/site/scripts/query_unix_partitions.pl get available /dev/sda4

which fails with

/bin/df: `/var/lib/lightdm/.gvfs': Permission denied

--Nico

[John Smith (espenxx)]

My backup scripts (which has been running silently for a long time) started to complain after I installed Ubuntu 12.04:

rsync: readlink_stat("/var/lib/lightdm/.gvfs") failed: Permission denied (13)

[Bryan Batten (bryanbatten)]

I've just done a dist-upgrade of 12.04 to 3.2.0-25-generic. The symptoms described by John Sopko (msg #12) still occur on my system. That is, if I have logged in locally, I can then log in via ssh and "df -H" works OK. However, if there is no one logged in locally, trying "df -H" from a ssh session gives me the ".gvfs" error message. But, if I do "sudo df -H" from the ssh session, there is no error message.

[Kees Bakker (keestux)]

This should not be marked as Fixed, because it isn't.

Even as 'root' you get an error when it is not expected.

$ sudo ls -l /var/lib/lightdm/
ls: cannot access /var/lib/lightdm/.gvfs: Permission denied
total 52
drwxr-x--- 10 lightdm lightdm 4096 Aug 9 12:31 .
drwxr-xr-x 93 root root 4096 Jul 6 16:32 ..
-rw------- 1 lightdm lightdm 49 Aug 9 12:31 .Xauthority
drwx------ 4 lightdm lightdm 4096 Jul 11 13:49 .cache
drwx------ 4 lightdm lightdm 4096 Jul 6 17:04 .config
drwx------ 3 lightdm lightdm 4096 Jul 6 17:02 .dbus
-rw------- 1 lightdm lightdm 16 Jul 6 17:12 .esd_auth
drwxr-xr-x 2 lightdm lightdm 4096 Jul 11 13:48 .fontconfig
drwx------ 2 lightdm lightdm 4096 Aug 9 12:31 .gconf
-rw------- 1 lightdm lightdm 49 Jul 12 10:39 .goutputstream-4YYRGW
d????????? ? ? ? ? ? .gvfs
drwxrwxr-x 3 lightdm lightdm 4096 Jul 6 17:03 .local
drwx------ 2 lightdm lightdm 4096 Aug 1 11:40 .pulse
-rw------- 1 lightdm lightdm 256 Jul 6 17:04 .pulse-cookie

Notice that we're _not_ reading the .gvfs directory, no we're just reading the home directory of user lightdm. The problem is that you can't even get the "stat" of that directory entry. So, even before the system can see whether there is read (or write) access you get an error. That's not how Unix systems suppose to work.

Does anyone know why lightdm needs that entry in the first place?

[Reinhard Tartler (siretart)]

The symptom still happens in quantal. System just started up, login via ssh:

>> df -hl
df: `/var/lib/lightdm/.gvfs': Permission denied
[...]

[Armand (armand-adrid)]

symptom persist in 12.04. This is under a vm and i doing a backup(dist) using remastersys:

it shows this error:

rsync: readlink_stat("/var/lib/lightdm/.gvfs") failed: Permission denied (13)

[Armand (armand-adrid)]

update:

error is not present if currently logged in to the system.

error details:

(not logged in):

Copying /var and /etc to temp area and excluding extra files ... this will take a while so be patient
rsync: readlink_stat("/var/lib/lightdm/.gvfs") failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.9]
Cleaning up files not needed for the live in /home/remastersys/remastersys/dummysys

(logged in):

Copying /var and /etc to temp area and excluding extra files ... this will take a while so be patient
Cleaning up files not needed for the live in /home/remastersys/remastersys/dummysys

[Piet Starreveld (pstarrev)]

Observed this issue on 12.04 LTS 32-bits and 64-bits versions. It apparently only occurs when nobody is logged into the console (graphical desktop) i.e. when the '/usr/lib/gvfs//gvfs-fuse-daemon -f /var/lib/lightdm/.gvfs' process is running.

The below comment describes how to find out whether your system is affected by this issue and some suggestions on how to work around it.

At the end of the day, as far as /var/lib/lightdm/.gvfs is concerned, most of the findings described in earlier comments imho can be explained perfectly well by the access permissions of /var/lib/lightdm/.gvfs.

The behavior of df when it comes to the gvfs-fuse-daemon mounts however is inconsistent/flawed. Even when fuse.gvfs-fuse-daemon type mounts are explicitly excluded using the --exclude-type option, df will still list your private gvfs mounts, but perhaps that's something for another bug :-)

Without any further ado:

# ensure nobody is connected to the console (graphical desktop) of the offending host;
# connect to the offending host remotely e.g. using ssh

 myuser@myhost2:~$ ssh myuser@myhost1

# list all mount points on the offending host and verify that
# /var/lib/lightdm/.gvfs is amongst them

 myuser@myhost1:~$ mount

  /dev/mapper/rootvg-rootlv on / type ext4 (rw,errors=remount-ro)
  .
  .
  .
  gvfs-fuse-daemon on /var/lib/lightdm/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=lightdm)

# verify that attempts to list the /var/lib/lightdm/.gvfs contents invariably
# result in 'Permission denied' errors even when executed with elevated
# privileges

 myuser@myhost1:~$ ls -la /var/lib/lightdm/ | grep .gvfs
 myuser@myhost1:~$ sudo ls -la /var/lib/lightdm/ | grep .gvfs

  ls: cannot access /var/lib/lightdm/.gvfs: Permission denied
  d????????? ? ? ? ? ? .gvfs

# this is because the only user allowed to list the contents of this
# 'private' mount is the lightdm user; the proof that lightdm is perfectly
# capable of listing the contents, is running the following command from the cli:

 myuser@myhost1:~$ sudo -u lightdm /bin/ls -la /var/lib/lightdm/.gvfs

  total 4
  dr-x------ 2 lightdm lightdm 0 okt 6 14:17 .
  drwxr-x--- 9 lightdm lightdm 4096 okt 6 14:17 ..

# now, if you just simply umount /var/lib/lightdm/.gvfs like so

 myuser@myhost1:~$ sudo umount /var/lib/lightdm/.gvfs

# it will lose its 'private' character and it will become available
# as an accessible directory again to both yourself, the root user

 myuser@myhost1:~$ ls -la /var/lib/lightdm | grep .gvfs
 myuser@myhost1:~$ sudo ls -la /var/lib/lightdm/ | grep .gvfs

  drwx------ 2 lightdm lightdm 4096 aug 12 15:13 .gvfs

# and to the lightdm user; do note that the dir has now become user writeable
# whereas previously it was only user readable(r) and user searchable(x)!

 myuser@myhost1:~$ sudo -u lightdm /bin/ls -la /var/lib/lightdm/.gvfs

  total 8
  drwx------ 2 lightdm lightdm 4096 aug 12 15:13 .
  drwxr-x--- 9 lightdm lightdm 4096 okt 6 14:17 ..

# since the mount has now disappeared and the directory has returned to being
# an accessible directory again, df and tools like rsync and tar do not have
# issues with it anylonger

 myuser@myhost...

[CBee (cbeerse)]

As far as I can see this issue (and 1006704 and probably more) is all about mount tools that read /etc/mtab or /proc/mounts and find a mountpoint that is inaccessable due to user access rights: The app is running as user A and finds this mountpoint belonging to user B, clearly stated in the /etc/mtab and /proc/mounts.

From my legacy unix ideas, I'd say the mounting application should mount this user-specific mountpoint using the '-n' option that it is not listed in /etc/mtab. The accessing tools like `mount`, `df`, `rsync` and others, should only use the mountpoints from /etc/mtab if they are run without root-rights. This avoids the listing problem.

With current knowledge and cases where /etc/mtab is linked to /proc/mounts, I'd say the accessing tools (`mount`, `df`etc) should check the "user" flag in the mount line and if the found uid does not match the current or active uid, the mount errors should silently be ignored (or the entire mount can be skipped).

[Yulianto (sehari24jam)]

I use this quick fix. Not sure if it is appropriate from security perspective:
sudo adduser <the user> lightdm

Doing that, will add "the user" into group lightdm.
Since directory /var/lib/lightdm has group read permission (drwxr-x---), thus "df" will not complain anymore.

[Alex T (captainrewind)]

Thanks for the workaround, Yulianto (sehari24jam)!!

[Daniel Barrett (dbarrett-m)]

The "adduser" workaround (#23) doesn't work under Ubuntu 13.04 because /run/user/lightdm is mode 700. :-(

[Marcin Dulak (marcin-dulak)]

The original problem with `df: `/var/lib/lightdm/.gvfs': Permission denied` still present on Ubuntu 12.04

[hamish (hamish-b)]

I've pretty much come to the conclusion at this point that gvfs is fundamentally broken for use on a UNIX system, and the authors have no intention of fixing it by observing the tradition of "everything is a file". Too bad, but the solution for us has been to migrate our systems to something else more friendly to multi-user deployments and error-free backups. If even root can't access a file in /home it's simply game over for whatever is putting the file there. We don't have to backup /dev, but we do have to backup /home.

regards

[Del Socorro Françoise (waterreedshimmer)]

For me everything is permission denied without sudo, but they all work well with sudo, althought last one, at 1st time did not work:
df -h
df: `/root/.gvfs': Permission denied (dissapeard with sudo)
+ answer

ls -la /var/lib/lightdm/ | grep .gvfs
ls: cannot open directory /var/lib/lightdm/: Permission denied (allowed with sudo)

dmidecode
# dmidecode 2.11
/dev/mem: Permission denied (only gets the answer with sudo)

[Petu Stenman (pstenman)]

The symptoms described by John Sopko (msg #12) still occur in my Ubuntu 12.04 (/proc/version says #81~precise1-Ubuntu SMP Tue Jul 15 04:02:22 UTC 2014).

[Marcos Marinho (marinho-marcos)]

I am using an Ubuntu 12.04 LTS on our servers and I am receiving this message when I am monitoring from Nagios.

root@mysever:# /usr/lib/nagios/plugins/check_disk -l -w 95 -c 99 -X tmpfs -X devtmpfs -A -i /localrepo
DISK CRITICAL - /var/lib/lightdm/.gvfs is not accessible: Permission denied

I saw the directory and it is showing to me this :

d????????? ? ? ? ? ? .gvfs

I will try an workaround on Nagios , excluding this directory using this command instead.

/usr/lib/nagios/plugins/check_disk -l -w 95 -c 99 -X tmpfs -X devtmpfs -A -i '.gvfs' -i /localrepo

[Marcos Marinho (marinho-marcos)]

This is the result, it worked just fine

DISK OK - free space: / 18951 MB (47% inode=89%); /var 4490 MB (86% inode=97%); /boot 728 MB (84% inode=99%);| /=20999MB;42017;42013;0;42112 /var=711MB;5408;5404;0;5503 /boot=130MB;826;822;0;921

[Chris Good (chris-good)]

As has already been said, this is also occurring in precise 3.2.0-86.124. Should 'precise' tag be added to this bug?

3.2.0-85.122 to 3.2.0-85.124 also gets error: df: `/sys/kernel/debug': Function not implemented
which I think is being fixed in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1465322

Similar gvfs error is also in trusty 3.13.0-53-generic #89-Ubuntu :
df: ‘/run/user/104/gvfs’: Permission denied

[Robert Ancell (robert-ancell)]

Should be nothing to do with lightdm..