Bug 723757 - fusermount couldn't umount successfully
Summary: fusermount couldn't umount successfully
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: fuse
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Josef Bacik
QA Contact: Jian Li
URL:
Whiteboard:
: 731186 (view as bug list)
Depends On:
Blocks: 752757 1020717
TreeView+ depends on / blocked
 
Reported: 2011-07-21 03:26 UTC by Jian Li
Modified: 2018-11-30 19:57 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1020717 (view as bug list)
Environment:
Last Closed: 2011-12-06 18:56:13 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1756 0 normal SHIPPED_LIVE fuse bug fix update 2011-12-06 01:01:42 UTC

Description Jian Li 2011-07-21 03:26:30 UTC
I am using  fuse-2.8.3-3.el6_1 and test machine is intel-d3c4702-01.rhts.eng.bos.redhat.com(x86_64).

problem:
[root@intel-d3c4702-01 fuse]# sudo -u fuse_tester fusermount
-u /mnt/tests/CoreOS/fuse/MP1
fusermount: failed to unmount /mnt/tests/CoreOS/fuse/MP1: Bad address

I scan the source, and do a little modification, and rebuild, it works.

@@ -411,7 +411,7 @@
 {
        int currdir_fd = -1;
        char *copy;
-       const char *last;
+       const char *last = mnt;
        int umount_flags = lazy ? UMOUNT_DETACH : 0;
        int res;

FYI:
In this function(unmount_fuse_locked)'s sentenses below my modification:

        if (umount_nofollow_support()) {
                umount_flags |= UMOUNT_NOFOLLOW;
        } else {
                res = check_is_mount(last, mnt);
                if (res == -1)
                        goto out;
        }
check_is_mount will not be executed.

Comment 2 RHEL Program Management 2011-07-21 03:58:05 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 3 Abraham Felsenstein 2011-08-08 10:08:32 UTC
(In reply to comment #0)
> I am using  fuse-2.8.3-3.el6_1 and test machine is
> intel-d3c4702-01.rhts.eng.bos.redhat.com(x86_64).
> 
> problem:
> [root@intel-d3c4702-01 fuse]# sudo -u fuse_tester fusermount
> -u /mnt/tests/CoreOS/fuse/MP1
> fusermount: failed to unmount /mnt/tests/CoreOS/fuse/MP1: Bad address
> 
> I scan the source, and do a little modification, and rebuild, it works.
> 
> @@ -411,7 +411,7 @@
>  {
>         int currdir_fd = -1;
>         char *copy;
> -       const char *last;
> +       const char *last = mnt;
>         int umount_flags = lazy ? UMOUNT_DETACH : 0;
>         int res;
> 
> FYI:
> In this function(unmount_fuse_locked)'s sentenses below my modification:
> 
>         if (umount_nofollow_support()) {
>                 umount_flags |= UMOUNT_NOFOLLOW;
>         } else {
>                 res = check_is_mount(last, mnt);
>                 if (res == -1)
>                         goto out;
>         }
> check_is_mount will not be executed.

Thankyou, I confirm this workaround works, but would prefer to have a Redhat supported workaround i can provide my customers.

We are seeing customers unable to unmount fuse based filesystems after having upgraded to Redhat 6.1 ( and automatically getting RHSA-2011-1083 ).

This is preventing us from gracefully shutting down.

Please reconsider including this in the current release.

Comment 4 Tim Jackson 2011-08-08 18:44:25 UTC
This is a regression.

For me, fuse-2.8.3-3.el6 refuses to unmount filesystems where a fuse filesystem is mounted on top of another fuse filesystem (e.g. encfs over sshfs)

Reverting to fuse-2.8.3-1.el6 fixes it.

Comment 6 Josef Bacik 2011-08-17 12:35:48 UTC
*** Bug 731186 has been marked as a duplicate of this bug. ***

Comment 8 Jian Li 2011-10-08 05:37:11 UTC
This bug is verified on rhel6.2. Test detail:


[root@ibm-x3650-01 sshfs-fuse-2.3]# sshfs localhost: /mnt/test
root@localhost's password: 
[root@ibm-x3650-01 sshfs-fuse-2.3]# fusermount -u /mnt/test
[root@ibm-x3650-01 sshfs-fuse-2.3]# uname -a
Linux ibm-x3650-01.rhts.eng.nay.redhat.com 2.6.32-203.el6test.x86_64 #1 SMP Thu Oct 6 03:13:01 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@ibm-x3650-01 sshfs-fuse-2.3]# rpm -q fuse
fuse-2.8.3-3.el6.x86_64
[root@ibm-x3650-01 sshfs-fuse-2.3]#

Comment 9 Tim Jackson 2011-10-10 10:32:38 UTC
(In reply to comment #8)
> This bug is verified on rhel6.2.

Jian, are you saying you verified a fix for the bug? The output you included doesn't show any errors, but the FUSE version you tested is the same one I had a problem with (see comment #4). Here is a reproducer for this bug:

cd $HOME
mkdir mnt-ssh mnt-crypt
sshfs user@host: mnt-ssh
encfs ~/mnt-ssh/crypt ~/mnt-crypt
fusermount -u mnt-crypt

The above still fails for me on fuse-2.8.3-3.el6_1.x86_64 .

Comment 10 Jian Li 2011-10-10 12:05:54 UTC
Change status to 'QA', bug I just test on i686, fuse work find with encfs, sshfs. Test on x86_64 need to be perfor..!

Comment 11 Jian Li 2011-10-11 02:33:40 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > This bug is verified on rhel6.2.
> 
> cd $HOME
> mkdir mnt-ssh mnt-crypt
> sshfs user@host: mnt-ssh
> encfs ~/mnt-ssh/crypt ~/mnt-crypt
> fusermount -u mnt-crypt
> 
> The above still fails for me on fuse-2.8.3-3.el6_1.x86_64 .

Hi, Tim, I retested as you said, fuse-2.8.3-3.el6.x86_64 works well, but fuse-2.8.3-3.el6_1.x86_64 fails.

Comment 12 Jian Li 2011-10-11 02:36:07 UTC
Hi josef,
fuse-2.8.3-3.el6_1 fails to umount as comment #4 said.

Comment 13 Jian Li 2011-10-11 03:09:00 UTC
hI josef,
Test is performed as Tim said(comment #9), and fuse-2.8.3-3.el6.x86_64 works ok, this bug is for rhel6.2, and package fuse-2.8.3-3.el6 should be used instead of fuse-2.8.3-3.el6_1. So could this bug be considered as VERIFIED?

[test@intel-mahobay-02 ~]$ sudo /usr/local/bin/sshfs test@localhost: test
test@localhost's password: 
[test@intel-mahobay-02 ~]$ sudo /usr/local/bin/encfs /home/test/test /home/test/enctest
Creating new encrypted volume.
Please choose from one of the following options:
 enter "x" for expert configuration mode,
 enter "p" for pre-configured paranoia mode,
 anything else, or an empty line will select standard mode.
?> p
****
later using encfsctl.

New Encfs Password: 
Verify Encfs Password: 
[test@intel-mahobay-02 ~]$ mount
**
test@localhost: on /home/test/test type fuse.sshfs (rw,nosuid,nodev,max_read=65536)
encfs on /home/test/enctest type fuse.encfs (rw,nosuid,nodev,default_permissions)
[test@intel-mahobay-02 ~]$ sudo fusermount -u /home/test/enctest 
[test@intel-mahobay-02 ~]$ sudo fusermount -u /home/test/test

Comment 19 Jian Li 2011-10-26 06:16:11 UTC
Hi josef, 
IMO, fuse package's version should be modified(increased), otherwise upgrading would be blocked, would not it?

Comment 20 Vincent Danen 2011-10-27 04:30:04 UTC
Absolutely it would:

[root@odvrhel6 Shared]# rpm -qa 'fuse*'
fuse-devel-2.8.3-3.el6_1.i686
fuse-libs-2.8.3-3.el6_1.i686
fuse-2.8.3-3.el6_1.i686
[root@odvrhel6 Shared]# ls fuse*rpm
fuse-2.8.3-3.el6.i686.rpm        fuse-libs-2.8.3-3.el6.i686.rpm
fuse-devel-2.8.3-3.el6.i686.rpm
[root@odvrhel6 Shared]# rpm -Fvh fuse*rpm
[root@odvrhel6 Shared]# 

You need to bump the nvr to 2.8.3-4.el6 for the upgrade to work.

Comment 21 Josef Bacik 2011-10-27 18:37:48 UTC
Yeah I'll fix it.  This is the problem with having a separate branch for async errata.

Comment 22 Jian Li 2011-11-05 07:04:00 UTC
Test the latest package:


[root@hp-xw9400-02 ~]# yum -y install fuse
** snip
---> Package fuse.x86_64 0:2.8.3-3.el6 will be installed
** snip
[root@hp-xw9400-02 ~]# rpm -FU fuse-2.8.3-4.el6.x86_64.rpm 
[root@hp-xw9400-02 ~]# rpm -q fuse
fuse-2.8.3-4.el6.x86_64


[root@hp-xw9400-02 sshfs-fuse-2.3]# sshfs localhost:./ /mnt/test
The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is c2:dc:d9:38:c5:f2:17:e7:26:5f:17:31:92:7a:fd:e6.
Are you sure you want to continue connecting (yes/no)? yes
root@localhost's password: 
[root@hp-xw9400-02 sshfs-fuse-2.3]# fusermount -u /mnt/test
[root@hp-xw9400-02 sshfs-fuse-2.3]# uname -a
Linux hp-xw9400-02.rhts.eng.bos.redhat.com 2.6.32-215.el6.x86_64 #1 SMP Fri Oct 28 18:13:32 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@hp-xw9400-02 sshfs-fuse-2.3]# rpm -qa | grep fuse
fuse-2.8.3-4.el6.x86_64
fuse-libs-2.8.3-4.el6.x86_64
fuse-devel-2.8.3-4.el6.x86_64

Comment 23 Richard W.M. Jones 2011-11-26 16:46:25 UTC
Also was reported to me that libguestfs 'guestmount'-ed
mountpoints could not be unmounted in RHEL 6.1.  Appears
to be an instance of this bug.

Comment 24 errata-xmlrpc 2011-12-06 18:56:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1756.html


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