Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
What is this strange .gvfs entry? The ls output looks bizare. I am assuming it has something to do with VirtualBox. Which I recently installed, created a VM, and the user is probably running at this time (either running, or in a "saved state").
Code:
# id
uid=0(root) gid=0(root) groups=0(root)
# mount
/dev/sda6 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda5 on /home type ext4 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/user1/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=user1)
# ls -al /home/user1 | grep .gvfs
ls: cannot access /home/user1/.gvfs: Permission denied
d????????? ? ? ? ? ? .gvfs
# ps -ef | grep gvfs
user1 1461 1 0 Sep13 ? 00:00:00 /usr/lib/gvfs/gvfsd
user1 1463 1 0 Sep13 ? 00:00:00 /usr/lib/gvfs//gvfs-fuse-daemon -f /home/user1/.gvfs
user1 1507 1 0 Sep13 ? 00:00:00 /usr/lib/gvfs/gvfs-gdu-volume-monitor
user1 1533 1 0 Sep13 ? 00:00:00 /usr/lib/gvfs/gvfs-afc-volume-monitor
user1 1536 1 0 Sep13 ? 00:00:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
user1 5195 1 0 Sep14 ? 00:00:00 /usr/lib/gvfs/gvfsd-http --spawner :1.4 /org/gtk/gvfs/exec_spaw/0
user1 19891 1 0 Sep16 ? 00:00:00 /usr/lib/gvfs/gvfsd-metadata
root 22091 21951 0 20:27 pts/0 00:00:00 grep --colour=auto gvfs
#
This is how I first noticed it, a non-trivial discrepancy between the size of /home as reported by df vs. du (plus the unexpected "permission denied" for root):
Code:
# pwd
/home
# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 100G 5.0G 90G 6% /home
# du -sh .
du: cannot access `./user1/.gvfs': Permission denied
3.4G .
#
It is a virtual filesystem used by the internals of the Gnome desktop. The contents have meaning only for the user and the Gnome session that created it, and even root cannot look inside it. Ignore it. It uses no space on disk. (The empty directory where it is mounted uses 1 disk block, of course.)
OK. Although this system does not have Gnome installed on it (it uses Xfce only, with no other installed desktops). However, certainly there are bits and pieces of Gnome and KDE present. There always are (usually), no matter what desktop the distro uses.
GVFS (Gnome Virtual File System) is used to mount remote file systems (like samba shares) and things like that. As mentioned above, XFCE uses this instead of creating its own thing, as it also does with networkmanager applet and other things.
FYI, my KDE desktop also implements GVFS. Or at least I have the following mount point:
gvfs-fuse-daemon on /home/rover/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=rover)
On a different system (see below), running the identical version of the OS (LinuxMint_13_Maya_Xfce_x64) I see the .gvfs mount, but the "ls -l" output on the directory is normal (mode 500). The "ls -l" output on the other system (see initial post) appears corrupted. What's up with that? I would think an fsck might be in order on the system with the corrupted looking "ls -l" output.
Code:
$ mount
/dev/sda4 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/user2/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=user2)
$ ls -al | grep gvfs
dr-x------ 2 user2 user2 0 Sep 17 11:49 .gvfs
$
Note that in the first case ls was being run by root, which does not have access to the .gvfs filesystem for user1. In the second case, the ls was run by a non-root user, presumably user2, which does have access to its own .gvfs.
Note that in the first case ls was being run by root, which does not have access to the .gvfs filesystem for user1. In the second case, the ls was run by a non-root user, presumably user2, which does have access to its own .gvfs.
Sure enough, that was it! I've never run into that before. I wasn't aware that a normal user operation could block root out of anything. Thanks!
Code:
$ id
uid=1000(user2) gid=1000(user2) groups=1000(user2),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),109(lpadmin),127(sambashare)
$ pwd
/home/user2
$ ls -al | grep gvfs
dr-x------ 2 user2 user2 0 Sep 17 11:49 .gvfs
$ sudo su
[sudo] password for user2:
# ls -al | grep gvfs
ls: cannot access .gvfs: Permission denied
d????????? ? ? ? ? ? .gvfs
#
FYI, those question marks do not indicate an error in the filesystem. When the ls command run by root issues a stat(2) system call to get the information for that directory, the call fails with EPERM (permission denied). The ls command is just displaying question marks for the information it could not retrieve. (There is a tag in the parent directory that indicates that .gvfs is a directory, but that is the only information available to the root UID.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.