Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

There's a directory underneath my homedir called ".gvfs". As my regular user account, I can read it just fine:

~ $ ls -lart ~raldi/.gvfs
total 4
dr-x------  2 raldi raldi    0 2009-05-25 22:17 .
drwxr-xr-x 60 raldi raldi 4096 2009-05-25 23:08 ..
~ $ ls -d ~raldi/.gvfs
dr-x------ 2 raldi raldi 0 2009-05-25 22:17 /home/raldi/.gvfs

However, as root I can't "ls" or even "ls -d" it:

# ls ~raldi/.gvfs
ls: cannot access /home/raldi/.gvfs: Permission denied
# ls -d ~raldi/.gvfs
ls: cannot access /home/raldi/.gvfs: Permission denied

And, just to make sure:

# echo $UID $EUID
0 0

This is just a simple home installation of Ubuntu 8.10, no NFS or anything weird like that. I see that the directory is marked non-world-readable (and non-world-x-able), but I thought none of that applied when you're root. For example, I can make a mode-000 directory in /tmp and give it away to a non-root user, and root has no trouble reading it, writing it, whatever.

Any idea what's going on?

share|improve this question
    
Interestingly, you get the same symptoms when using sshfs as a regular user, and then attempting any sort of operation on the mount point as root. The root user has no permissions to view the mount point at all. You can't even see the permissions, ls -l returns all question marks for all the permission bits. –  GodEater May 26 '09 at 6:54
    
"This is just a simple home installation of Ubuntu 8.10, no NFS or anything weird like that". Uhm, fuse is "something weird like that" –  Thomas Jun 10 '09 at 7:51
add comment

3 Answers

up vote 14 down vote accepted

From: http://bugzilla.gnome.org/show_bug.cgi?id=534284

This is all unfortunate, but its a decision that has been taken by the fuse people at the kernel level (user others than the one who mounted the fs can't access it, including root) and there is nothing we can do about it.

Also see: https://bugs.launchpad.net/gvfs/+bug/225361

The solution seems to be to update your /etc/fuse.conf and enable the user_allow_other option. You may also need to then get gvfs to pass the allow_root or allow_other, but I am not sure how to do this.

Of course it may be much easier to simply give up on all the GUI tools like gvfs and mount your filesystems from command line where you have complete control of exactly how something gets mounted.

share|improve this answer
add comment

The .gvfs directory is the Gnome VFS userspace filesystem that provides a direct filesystem path for virtual filesystems (e.g. remote samba mounts, webdav mounts) so Gnome can pass paths to programs that aren't VFS-aware when operating on remote files.

Since it's a FUSE mount & application it can deny permissions to root - the agent performing the access checks in this case is the FUSE application, not the kernel.

By default the gvfs daemon only allows the owner to traverse the directory.

share|improve this answer
add comment

It could be a few things, in order of likelyhood

  • check /var/log/messages (or /var/log/syslog) for possible filesystem corruption
  • are you using SELinux ?
  • google suggests lsattr ~raldi/.gvfs may indicate special capabilities being applied to that file.
share|improve this answer
    
I ran fsck on the disk and it didn't find any problems. I'm not using SELinux. If i run lsattr as my user account, there is no output. If i run it as root, I get a "permission denied" error. –  raldi May 26 '09 at 6:31
    
Looks like Zoredache has the answer –  Dave Cheney May 26 '09 at 7:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.