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@myhost1:~$ df -Ph
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv 1,9G 350M 1,4G 20% /
.
.
.
/dev/mapper/rootvg-usrloclv 3,7G 72M 3,5G 3% /usr/local
# when you're done rsync'ing or tar'ing or whatever, remember to
# reinstate the /var/lib/lightdm/.gvfs 'private' mount like so:
myuser@myhost1:~$ sudo service lightdm restart
lightdm stop/waiting
lightdm start/running, process 7677
# and verify that the /var/lib/lightdm/.gvfs shows up in the mount table
again
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)
# while the umount workaround is ok for (shell scripted) backups
# (that, by nature, often run with enhanced priviliges), you probably don't
want
# go through that for each df that you run from the cli, just to prevent the
annoying
# 'Permission denied' from popping up
myuser@myhost1:~$ df -Ph
df: `/var/lib/lightdm/.gvfs': Permission denied
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv 1,9G 350M 1,4G 20% /
.
.
.
/dev/mapper/rootvg-usrloclv 3,7G 72M 3,5G 3% /usr/local
# one elegant workaround for that would be to use the exclude-type option of df
# to exclude the fuse.gvfs-fuse-daemontype from the df output like so
myuser@myhost1:~$ df -Ph --exclude-type=fuse.gvfs-fuse-daemon
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv 1,9G 350M 1,4G 20% /
.
.
.
/dev/mapper/rootvg-usrloclv 3,7G 72M 3,5G 3% /usr/local
# and depending on your demands you might even want to create an alias
# for that or go wild and stuff the alias definition in your ~/.bashrc
# (if it's bash you're using, that is)
myuser@myhost1:~$ alias df='df --exclude-type=fuse.gvfs-fuse-
daemon'
# another, possibly even more elegant workaround for this 'issue' would be
# to become a member of the lightdm user group (i.e. add
# your userid to the lightdm group) like so
myuser@myhost1:~$ sudo usermod -a -G lightdm myuser
# subsequently log out
myuser@myhost1:~$ exit
logout
Connection to myhost1 closed.
# and log back in again to make your shell environment aware of your userid
# having been added to the lightdm group
myuser@myhost2:~$ ssh myuser@myhost1
# and enjoy the fact that the 'Permission denied' message has both finally
# and persistently disappeared from your df output
myuser@myhost1:~$ df -Ph
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv 1,9G 350M 1,4G 20% /
.
.
.
/dev/mapper/rootvg-usrloclv 3,7G 72M 3,5G 3% /usr/local
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/867806
Title:
df -h permission denied error
To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/867806/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
