Hi, thanks for reporting this bug.
Assigned to the package maintainer.

Assignee: bugsquad => tmb
Keywords: (none) => Triaged

I have the same issue with an auto-mounted FAT32 partition on a USB connected drive.

Of course this has no entry in fstab.

CC: (none) => richard.j.walker

Trying to ping 41 bug reports in one move, because nothing has happened with them for more than 3 months, they still have the status NEW or REOPENED, there is no "OK" on the Whiteboard and severity and priority are "normal" or higher.

Is this one still valid for Mageia 2 rc?

If it is and you're the assignee, please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead.
If it wasn't assigned correctly, please assign back to Bug Squad and explain.

This bug is still valid with a current cauldron installation.

Official Mageia 2 also! :-(

For example:

fstab: (detail)
# Entry for /dev/sdb5 :
UUID=E86D-A1B2 /mnt/winswap vfat umask=000,user,iocharset=utf8,noauto 0 0

or
# webdav acces
https://www.box.com/dav /home/csablak/Box davfs rw,user,noauto 0 0

user mount ok, umount just root.
(webdav bug 3828)

CC: (none) => csablak

(In reply to comment #5)
> Official Mageia 2 also! :-(
> 
> For example:
> 
> fstab: (detail)
> # Entry for /dev/sdb5 :
> UUID=E86D-A1B2 /mnt/winswap vfat umask=000,user,iocharset=utf8,noauto 0 0
> 
> or
> # webdav acces
> https://www.box.com/dav /home/csablak/Box davfs rw,user,noauto 0 0
> 
> user mount ok, umount just root.
> (webdav bug 3828)

Does the workaround of using users instead of user in the fstab
entry also work with the webdav access?

Created attachment 2370 [details]
webdav access

webdav access

Although it is not here belongs. Please look attachment.

Comment on attachment 2370 [details]
webdav access

>webdav acces:
>su
>urpmi davfs2
>rm-f /usr/sbin/mount.davfs2
>rm-f /usr/sbin/umount.davfs2
>rm-f /sbin/mount.davfs2
>rm-f /sbin/umount.davfs2
>ln-s /usr/sbin/mount.davfs /sbin/
>ln-s /usr/sbin/umount.davfs /sbin/
>
>edit /etc/davfs2/davfs2.conf
>ignore_home       kernoops,distccd
>use_locks       0
>
>edit /etc/davfs2/secrets
>/home/user/Box login password
>chmod 600 /etc/davfs2/secrets

oops this left out
usermod -G davfs2 user_name
>
>fstab
>https://www.box.com/dav /home/user/Box davfs rw,user,noauto 0 0
>
>exit su
>
>right click kde desktop
>New/device/hdd partition select https... 
>change icon
>right click mount umount ok.
>
>Gnome desktop
>right click tray, add widget device mount.
>

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

I do not know why I got the email, I am not a developer, but the problem persists.
A little help

Mageia 1:
$ mount /mnt/winswap/

$ cat /etc/mtab | grep win
/dev/sdb5 /mnt/winswap vfat rw,noexec,nosuid,nodev,umask=000,iocharset=utf8,user=csablak 0 0

$ umount /mnt/winswap/

**************************

Mageia 2:
$ mount /mnt/winswap/

$ cat /etc/mtab | grep win
/dev/sdb5 /mnt/winswap vfat rw,nosuid,nodev,noexec,relatime,uid=10001,gid=10001,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0

$ umount /mnt/winswap/
umount: csak a(z) root felhasználó választhatja le a(z) UUID=E86D-A1B2 eszközt a(z) /mnt/winswap alól

Just root umount this device.

This bug still exists in Mageia 2, as was stated in comment #5.  Please fix.

Version: Cauldron => 2
CC: (none) => rmriches

Oh, it also affects x86_64, not just i586.  I don't have an ARM system to test it with, but I suspect it also affects ARM.

I tried backporting the util-linux-2.23.1 version from cauldron, and the problem is solved. I don't see anything directly related to this problem in the changelogs, but there are a ton of fixes.

CC: (none) => dan

I should say my tests were on Mageia 2 ix86

Does the version in Mageia 3 work?

This sounds like it might be relevant from the 2.22.1 changelog:
    libmount: don't remove user= when executed by root
    
    The original mount(8) allows to store arbitrary user= option to mtab
    file if called by root user. For example:
    
      # mount -f foo /bar -t xxx -o rw,user=kzak
    
    the new mount removes the 'user=' and 'users' options at all for root
    user. This is regression. The original functionality is necessary by
    'sshfs' where fuse writes to mtab file by mount(8).
ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.22/v2.22.1-ChangeLog

That also appears in the 2.23-rc1 changelog, and 2.23-rc2 has this:
    libmount: fix user-mount by root for mount.<type> helpers
    
    Append options like "exec" "suid" and "dev" to mount.<type> helpers
    command line if the options are in fstab. This is relevant for root
    user who calls mount(8) for fstab entries with "user,exec" etc.
ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.23/v2.23-rc1-ChangeLog
ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.23/v2.23-rc2-ChangeLog

I rebased upstream commit 4be900c5 onto the Mageia 2 version and it alone wasn't enough to solve this issue.

(In reply to Dan Fandrich from comment #18)
> I rebased upstream commit 4be900c5 onto the Mageia 2 version and it alone
> wasn't enough to solve this issue.

Which one is that?

Which one what? Which patch? The upstream commit I referenced, which is the one from 2.22.1 you mentioned. There don't seem to be any mount.<type> helpers involved here. Which issue?  The one this bug is about: fstab entry with user option allows mounting, but not unmounting.

(In reply to Dan Fandrich from comment #20)
> Which one what? Which patch? The upstream commit I referenced, which is the
> one from 2.22.1 you mentioned. There don't seem to be any mount.<type>
> helpers involved here. Which issue?  The one this bug is about: fstab entry
> with user option allows mounting, but not unmounting.

I don't see a 4be900c5 in any of those changelogs I linked.  The first one I mention has these commit ids:
d555b969b6fb219b041491b7fa3262682fc45acc 2.22 branch
4be900c51d371a7a41495e4eca2d29fc77c20c7c 2.23 branch

The second one is:
17206c059dc2e42e7081079b76eafda68cc9a5b8

Where'd you get the actual patch?

Also, again, does the version in Mageia 3 work?

The commit I used was from the master branch: https://git.kernel.org/cgit/utils/util-linux/util-linux.git/patch/?id=4be900c51d371a7a41495e4eca2d29fc77c20c7c

I didn't try the Mageia 3 binary since it has too many newer dependencies (including glibc), but when I rebuilt it (util-linux-2.22.2-5) for Magiea 2, it solved this problem as well.

OK.  It sounds like we've identified the correct patch, but that the fix is dependent on some previous patches to actually work.

I git bisected the v2.22 branch to try to find what fixed the problem in v2.22. The last failing commit was:

commit 964339a986997a11fe6a0baab633ecef901b4398
Author: Karel Zak <kzak@redhat.com>
Date:   Wed May 30 17:17:49 2012 +0200

    mount: (old) remove mtab lock test

and the first working commit was:

commit 8772f8d7eeeb922bccee3376552c59d7148df7b4
Author: Karel Zak <kzak@redhat.com>
Date:   Tue Jun 26 18:06:21 2012 +0200

    build-sys: convert sys-utils/ to module

(There are 5 commit in between that wouldn't build in my test environment). Unfortunately, commit 8772f8d7 completely changed the source base used to build mount/umount, from mount-deprecated/mount.c to sys-utils/mount.c. So, it's likely that there's no simple patch that can be taken from git to solve this problem. It will take some old-fashioned debugging to figure it out instead.

HOWEVER, the sys-utils version of mount is also available in util-linux-2.21.1 and can be enabled with the --enable-new-mount configure option. Adding that flag solves this problem for me, without touching the source code. But, that could have other effects on mount's behaviour, which may be undesired in a stable release.

I've looked into what it would take to add user support to the deprecated umount, and it's not easy. The new mount (which uses libmount) tracks which user mounted what device in the file /run/mount/utab, and umount is responsible for cleaning that file when the device is unmounted. The deprecated umount does not. This support would need to be added, and since the new version uses libmount to handle all this, it would not be easy to port.

If adding --enable-new-mount is not an option due to the risk of behavioural changes in a stable release, then I suggest this bug be closed as WONTFIX.

At the risk of opening a can of worms, the workaround of specifying a specific user allowed to mount/umount, like "user=notme", is broken, too, but that one should be much easier to fix if desired.

I should note that I wasn't able to prove that it was working on Mageia 1 (actually, the Mageia 1 version of util-linux-ng-2.18 built on Mageia 2) as stated in the original comment. I don't see how it could have worked, given that the permissions checking code in umount.c hasn't really changed since then.

My RCS archive of historical /etc/fstab indicates I changed my CDROM entry from 'user' to 'users' when I went from Mandriva 2010 to Mageia 1.  That would seem to support the theory that it was broken in Mageia 1.

In terms of a bug fix for Mageia 2, I would suspect there are very few users who don't already have a tolerable workaround in place and are still using Mageia 2 and aren't going to be shortly moving to Mageia 3.  In my case, I have a tolerable workaround.  I'm not the original reporter, but if this were to be closed as WONTFIX, the amount of unhappiness that would cause me would be considerably lower than most WONTFIX reports I have been affected by over the years.

(changing version as it seems still valid on mga3, eol of mga2 )

Version: 2 => 3

This is a Mageia 2 bug.

Version: 3 => 2

(In reply to Manuel Hiebel from comment #28)
> (changing version as it seems still valid on mga3, eol of mga2 )

Note that Mageia 2 will not be eol until November 22nd, 2013
http://www.mageia.org/en/support/

I can confirm this bug is not currently present in Mageia 3, at least on
my system, with the updates testing kernel 3.10.15-desktop-1.mga3 in use.

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Closing this now due to Mageia 2 EOL.

http://blog.mageia.org/en/2013/11/21/farewell-mageia-2/

Resolution: (none) => OLD
Status: NEW => RESOLVED