maindavfs2 - Support: sr #108638, umount passes -t flag to...

 
 

sr #108638: umount passes -t flag to umount.davfs, davfs exits with error

Submitter:  Janis Beckert <superfluffy>
Submitted:  Wed 20 Aug 2014 01:52:27 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 23 Aug 2014 06:26:53 PM UTC, comment #5: 

I added option t to umount.davfs (and ignore it). This should fix the problem.

A new release 1.5.2 with this bugfix is now available.

Werner

- <_71007>
Thu 21 Aug 2014 07:47:33 PM UTC, comment #4: 

Thanks for reporting this to the util-linux bug tracker. As far as I understand they will revert this API-change.

Nevertheless I will prepare a bug fix for davfs2 to ignore this option (maybe this weekend).

Karel Zak is right that umount helpers should be able to accept all possible options. But it is hard to keep up with a moving target like mount and umount, especially when changes are that badly documented (or not documented in the man page at all). And I still can't see what should have been the reason for this change, that breaks existing applications.

Regarding mtab:
When mtab is a symlink to /proc/mounts then the file system is reported as fuse and the user= option is missing. This problem is solved by an additional file /var/run/utab (mostly undocumented). davfs2 uses this file and mount will show a combination of /proc/mounts and /var/run/utab. This makes sure that the user= option works and the correct umount helper is called (optin helper=davfs).
Why is there no entry in /proc/self/mounts? On my system there is one. Did you mount as root but list /proc/self/mount as normal user?

Regarding fusermount:
I really want to be able to mount and unmount a davfs2 file system with the standard mount and umount commands. At some time I thought of using file type fuse.davfs because there is a mount.fuse helper that would be able to mount a davfs2 file system (calling mount.davfs). But I could not find a umount.fuse helper. So I stopped this development.
Another point would be to use fusermount for mounts of unprivileged users (instead of fstab option user). But this looks like a lot of work, more than I will be able to do in the near future.

Werner

- <_71007>
Wed 20 Aug 2014 08:25:44 PM UTC, comment #3: 

I wanted to add, that I submitted a bug report to util-linux, which you can see here:
https://github.com/karelzak/util-linux/issues/116

Janis Beckert <superfluffy>
Wed 20 Aug 2014 08:20:05 PM UTC, comment #2: 

Okay, this is quite interesting. Because you have mentioned fuse, I did try unmounting the filesystem using fuse and it worked, i.e.:
% fuserumount -u /path/to/davfs

This is for the dav filesystem I have an entry in my /etc/fstab for:

https://dav.box.com/dav /home/janis/box.com davfs user,noauto,uid=janis,file_mode=600,dir_mode=700 0 1


Do make sure that this does not affect the problem, I mounted the same remote filesystem using root:
# mount -t davfs https://dav.box.com/dav /mnt/box.com
Please enter the username to authenticate with server
https://dav.box.com/dav or hit enter for none.
  Username: -email is unavailable-
Please enter the password to authenticate user -email is unavailable- with server
https://dav.box.com/dav or hit enter for none.
  Password:

I have attached the full output in the file “mount-root”. Unmounting /mnt/box.com as root, i.e. # umount /mnt/box.com, yields the same results as reported above. However, # fusermount -u /mnt/box.com works (as root!).


It further turns out that /etc/mtab is indeed a symlink on my distribution:
% ls -l /etc/mtab
lrwxrwxrwx 1 root root 19 Jul  7 18:33 /etc/mtab -> ../proc/self/mounts

And furthermore, there is no entry for davfs in that /proc/self/mounts.

The entry for the the davfs filesystem is:
% mount | grep dav
https://dav.box.com/dav on /mnt/box.com type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,max_read=16384,uid=0,gid=0,helper=davfs)


I have checked how Archlinux is building davfs, and it looks pretty vanilla to me. Here is a link to the PKGBUILD file, which does not contain any patches.

Janis Beckert <superfluffy>
Wed 20 Aug 2014 06:43:37 PM UTC, comment #1: 

I have tested with umount from util-linux 2.20.1 and don't get the -t option.

The man page of umount (version 2.20.1) says:

"       The syntax of external umount helpers is:

       /sbin/umount.<suffix> {dir|device} [-nlfvr] [-t type.subtype]

       where  the  <suffix>  is filesystem type or a value from "uhelper=" or
       "helper=" mtab option.  The -t option is used   for  filesystems  with
       subtypes support (for example /sbin/mount.fuse -t fuse.sshfs)."

davfs2 does not support subtypes and is not a fuse file system. If your system has a real mtab (not a symlink) davfs2 writes an mtab entry with fs-type davfs. If your mtab is a symlink then davfs2 sets the option helper=davfs.

So according to the man page the -t option must not be passed to umount.davfs.

I can see two possible reasons why -t is passed to umount.davfs on your system:

  • The interface of umount for umount helpers has changed (which would be bad style)


  • There is something wrong with your configuration.


Please send me this information:

  • the line from fstab or - if mounted without an fstab entry - the full command line you use for mounting


  • the output of 'mount' (without parameter); only the entry concerning this file system.


  • if you have any information about patches applied to the davfs2 sources by Archlinux, they might help too.


Cheers
Werner

- <_71007>
Wed 20 Aug 2014 01:52:27 PM UTC, original submission:  

I am using the following packages/versions of davfs2 and umount (from util-linux):
util-linux 2.25-3
davfs2 1.5.0-1
on Archlinux:
3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux

I have a remote filesystem mounted through davfs2 (a box.com account through their webdav interface, and also a webdav interface provided by my university).

When trying to unmount either filesystem by invoking umount, I get the following error message:
% unalias umount # Make sure that there are no custom options
% umount box.com
/sbin/umount.davfs: invalid option -- 't'
/sbin/umount.davfs: too many arguments
zsh: exit 1     umount box.com


Invoking umount.davfs directly, however, works:
% umount.davfs box.com
umount.davfs: waiting while mount.davfs (pid 6095) synchronizes the cache .. OK

I have attached a more verbose output of umount by running % env LIBMOUNT_DEBUG=0xffff umount box.com . You can see the result in the attached file “umount.log”

The interesting part is:
13340: libmount:      CXT: [0x1620110]: argv[0] = "/sbin/umount.davfs"
13340: libmount:      CXT: [0x1620110]: argv[1] = "/home/janis/box.com"
13340: libmount:      CXT: [0x1620110]: argv[2] = "-t"
13340: libmount:      CXT: [0x1620110]: argv[3] = "fuse"
/sbin/umount.davfs: invalid option -- 't'
/sbin/umount.davfs: too many arguments


So obviously umount attempts to pass the options “-t fuse” to umount.davfs, which in turn chokes on the -t flag, because it is not in the list of accepted/ignored flags in src/umount_davfs.c .


Janis Beckert <superfluffy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #31927:  mount-root added by superfluffy (4KiB - application/octet-stream)
file #31923:  umount.log added by superfluffy (9KiB - text/x-log - Verbose log of umount)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by superfluffy (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-15 _71007 Open/ClosedOpen Closed
    2014-08-23 _71007 StatusIn Progress Done
    2014-08-20 superfluffy Attached File- Added mount-root, #31927
    2014-08-20 _71007 StatusNone In Progress
        Assigned toNone _71007
    2014-08-20 superfluffy Attached File- Added umount.log, #31923

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code