Bug 1121021

Summary: coreutils-8.21-21.fc20.x86_64 df (executed by root) does not show fuse.sshfs mount
Product: [Fedora] Fedora Reporter: vikram goyal <vikigoyal>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: admiller, kdudka, kzak, ooprala, ovasik, pbrady, p, twaugh, vikigoyal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-12 17:20:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description vikram goyal 2014-07-18 08:04:22 UTC
Description of problem:
I used sshfs to mount a remote location in a user dir as a normal user.
The mount was successful. After doing my work I executed df by root which did not show fuse mount but executed as the same user the fuse mount showed in df.

Version-Release number of selected component (if applicable):


How reproducible:
Mount a remote location in home dir/dir through sshfs as a normal user
execute df as root
excute df as the same uaer which mounted the remote location.

Steps to Reproduce:
1.
2.
3.

Actual results:
[vikram@mail2 ~]$ df
Filesystem                1K-blocks      Used Available Use% Mounted on
/dev/sdb6                 153942744  66849904  84503912  45% /
devtmpfs                    1520368         0   1520368   0% /dev
tmpfs                       1527604     99060   1428544   7% /dev/shm
tmpfs                       1527604       932   1526672   1% /run
tmpfs                       1527604         0   1527604   0% /sys/fs/cgroup
tmpfs                       1527604       708   1526896   1% /tmp
/dev/sda1                   1515376    172140   1248212  13% /boot
/dev/dm-0                 330327632 240421328  87183640  74% /home/vikram
root.XXX.XXX:/root  51606140   3660076  45324624   8% /home/vikram/someremoteloc


[root@mail2 ~]# df
Filesystem                1K-blocks      Used Available Use% Mounted on
/dev/sdb6                 153942744  66850280  84503560  45% /
devtmpfs                    1520368         0   1520368   0% /dev
tmpfs                       1527604     99060   1428544   7% /dev/shm
tmpfs                       1527604       932   1526672   1% /run
tmpfs                       1527604         0   1527604   0% /sys/fs/cgroup
tmpfs                       1527604       708   1526896   1% /tmp
/dev/sda1                   1515376    172140   1248212  13% /boot
/dev/dm-0                 330327632 240421552  87183456  74% /home/vikram

[root@mail2 ~]# uptime
 13:20:10 up 7 days, 19:14, 15 users,  load average: 0.21, 0.18, 0.48

[root@mail2 ~]# uname -a
Linux mail2.xxx 3.15.3-200.fc20.x86_64 #1 SMP Tue Jul 1 16:18:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[root@mail2 ~]# rpm -qf `which sshfs`
fuse-sshfs-2.4-5.fc20.x86_64

Expected results:
command 'mount' as a normal user & as root shows the fuse mount in output.

Additional info:
It seems to be a bug. If not, please excuse me for unnecessary noise.
Thanks

Comment 1 Ondrej Vasik 2014-07-18 10:42:01 UTC
Maybe this is because of the deduplication - can you see the mountpoint with df -a ? 
Deduplication was necessary for default listing, as /etc/mtab is now symlink to /proc/mounts - and this contains quite a lot of duplicate entries in comparison to the former /etc/mtab mountlist. Some logic is there, some improvements are expected/in todo. There is already some report about issues with fuse mounts, so to some extent it is a duplicate report.

Comment 2 Pádraig Brady 2014-07-18 15:12:08 UTC
Is the root user able to access /home/vikram/someremoteloc
I know the root user should be able to do anything,
but I remember issues with root user access with libguestsfs fusemount setup for example

Comment 3 Ondrej Vasik 2014-10-30 06:05:55 UTC
Ping? Without additional information, this will go closed insufficient data.

Comment 4 Ondrej Vasik 2014-11-12 17:20:54 UTC
Closing insufficient data, feel free to reopen if you can answer questions from comment #1 and #2.

Comment 5 Red Hat Bugzilla 2023-09-14 02:11:42 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days