Let's suppose that I have mount using CIFS, and the server dies. I would like to be able to umount the mount point. mount.cifs does a statfs on the mountpoint and, if this mountpoint is not available, fails. Apart from having to wait for the timeout, the umount fails, and there is no way to remove the entry. This makes all the normal programs hang, df, lsof .... As far as I can tell, assuming that the user is sure that it is a cifs mount point, there is no reason to perform this check. Calling umount2 directly and changing /etc/mtab is all that is needed. Maybe the -f flag could be used to avoid the check. rc = statfs(mountpoint, &statbuf); if(rc || (statbuf.f_type != CIFS_MAGIC_NUMBER)) { printf("This utility only unmounts cifs filesystems.\n"); return -EINVAL; }
My observation is that both version 3.0.28a (Ubuntu 8.04) and 3.3.2 (Ubuntu 9.04) unmount the share after the timeout. The delay is disruptive and annoying, however, and I concur that there is no reason to wait if the mountpoint is identified as type cifs in mtab. Requiring the -f flag to enable the alternative mtab check would be reasonable however.
If you rename /sbin/umount.cifs so that it's not found by /bin/umount, does this problem still occur? In the master samba branch, umount.cifs is no longer built by default since it's not really needed, so this may just be a matter of having the distro packagers not ship it.
Hiding /sbin/umount.cifs reduces the delay but does not eliminate it when unmounting a disconnected share using /bin/umount. Delays with umount.cifs hidden ranged from 18 to 27 seconds in four trials. With umount.cifs exposed, delays of 30 to 53 seconds were observed, also over four trials. I do not agree that umount.cifs is no longer needed. My share mounting management system, written in shell script, depends on mount.cifs and umount.cifs installed suid to allow automatic mount/unmount of shares for normal users without granting them universal mount privileges.
If you're dependent upon making umount.cifs setuid root, then you'll also probably need to build mount.cifs with its legacy setuid behavior enabled. Personally, I don't recommend it since you're granting unprivileged users more permission than they should have, but its your environment. Care to propose a patch with what you'd like to see umount.cifs do? That'll give us a concrete starting point for discussion.
I haven't looked at the source code (my C experience is little and long ago), I simply made use of the suid behavior of *mount.cifs in the distros I developed my scripts on: Ubuntu 8.04 and 9.04, Fedora 10 and 11, Slackware 12.2 and 13.0, and PCLinuxOS 2009.2. It seems to me that the code suggested by Peter Gordon in his original post is a good place to start. I think his point is valid. If we know it is a cifs filesystem, why do we have to check?
I'm sorry, I'm a little unclear on this point...how do we know that the filesystem in question is CIFS? It's certainly possible for a user to call umount.cifs directly, so you can't count on /bin/umount to do that for you.
Perhaps I misinterpreted Peter's original report. I took it to suggest that mtab could be consulted to verify a cifs filesystem and allow umount.cifs to proceed without delay if the server was unreachable. On review, however, he seems to propose that the -f flag could be used to skip the check entirely based on the user's conviction that it is a cifs filesystem. I am more than unclear, I am now confused. Hopefully Peter will weigh in and clarify his intent.
The main problem still remains the same. Add a CIFS mount point and some time after, have the server go down and issue a umount. Umounting ========= I don't want to check the state of the server, as it seems to be irrelevant. The mount point can be found from the file /etc/mtab, so why not just rely on that? Do the umount2 and change the mtab accordingly. The -f flag =========== Assuming that umount.cifs issues a umount2 call and then changes /etc/mtab, there is no need for a -f flag. If however, the /etc/mtab file gets changed first, and the program is aborted before it gets to the umount2 command, the next time umount.cifs is run, the type of the filesystem will not be able to be verified, so a -f flag would be useful. I hope that I haven't muddied the waters still further.
I'm a little leery of trusting the mtab to that degree. It's often the case that the information in it is incomplete or wrong. umount.cifs should probably be fixed to not change the mtab unless the umount actually succeeds too... I also wouldn't want to trust the "-f" flag in the fashion you suggest for anyone but the actual root user. Allowing any user to just pass "-f" and unmount any filesystem seems a bit dangerous. There is another way to determine the fstype for the mount. If /proc/self/mounts exists, then you could walk it instead of the mtab to determine it. That's a bit more difficult to spoof than the mtab. That should (in principal) get around a statfs call. Before you go down that path though, it might be best to post an strace of the umount.cifs call with timing info so we can determine how long each syscall is actually taking. i.e.: # strace -f -T -tt -o /tmp/umount.strace /sbin/umount.cifs /path/to/dead/cifs/mount ...then attach /tmp/umount.strace to this BZ.
Created attachment 4733 [details] strace of umount.cifs unreachable_share I had to run sudo. When run as user I got: mike@stealthwork:~$ strace -f -T -tt -o /tmp/umount.strace /sbin/umount.cifs /home/mike/Public Trying to unmount when /sbin/umount.cifs not installed suid Although umount.cifs was in fact set suid: mike@stealthwork:~$ ls -l /sbin/umount.cifs -rwsr-sr-x 1 root root 14000 2009-07-08 00:28 /sbin/umount.cifs I mention this in case it might have affected any of the timings.
Updating component.
Since cifs-utils no longer ships this tool, I'm closing this bug as WONTFIX. Please reopen if you wish to discuss it further.