Bug 1121021 - coreutils-8.21-21.fc20.x86_64 df (executed by root) does not show fuse.sshfs mount [NEEDINFO]
Summary: coreutils-8.21-21.fc20.x86_64 df (executed by root) does not show fuse.sshfs ...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-18 08:04 UTC by vikram goyal
Modified: 2014-11-12 17:20 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-12 17:20:54 UTC
ovasik: needinfo? (vikigoyal)


Attachments (Terms of Use)

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@125.XX.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.


Note You need to log in before you can comment on or make changes to this bug.