<p>I have  a CIFS share mounted on a Linux machine.  The CIFS server is down, or the internet connection is down, and anything that touches the CIFS mount now takes several minutes to timeout, and is unkillable while you wait.  I can't even run ls in my home directory because there is a symlink pointing inside the CIFS mount and ls tries to follow it to decide what color it should be.  If I try to umount it (even with -fl), the umount process hangs just like ls does.   Not even sudo kill -9 can kill it.  How can I force the kernel to unmount?</p>

[{'answer_id': 74695, 'author': 'Chris AtLee', 'author_id': 4558, 'author_profile': 'https://Stackoverflow.com/users/4558', 'pm_score': 2, 'selected': False, 'text': '<p>There\'s a -f option to umount that you can try:</p>\n\n<pre><code>umount -f /mnt/fileshare\n</code></pre>\n\n<p>Are you specifying the \'-t cifs\' option to mount?  Also make sure you\'re not specifying the \'hard\' option to mount.</p>\n\n<p>You may also want to consider <a href="http://www.ricardis.tudelft.nl/~vincent/fusesmb/" rel="nofollow noreferrer">fusesmb</a>, since the filesystem will be running in userspace you can kill it just like any other process.</p>\n'}, {'answer_id': 74837, 'author': 'Sunny Milenov', 'author_id': 8220, 'author_profile': 'https://Stackoverflow.com/users/8220', 'pm_score': 2, 'selected': False, 'text': '<p>Try umount -f /mnt/share. Works OK with NFS, never tried with cifs.</p>\n\n<p>Also, take a look at autofs, it will mount the share only when accessed, and will unmount it afterworlds.</p>\n\n<p>There is a good tutorial at <a href="http://www.howtoforge.com/accessing_windows_or_samba_shares_using_autofs" rel="nofollow noreferrer">www.howtoforge.net</a></p>\n'}, {'answer_id': 96288, 'author': 'Kemal', 'author_id': 7506, 'author_profile': 'https://Stackoverflow.com/users/7506', 'pm_score': 9, 'selected': True, 'text': "<p>I use lazy unmount: <code>umount -l</code> (that's a lowercase <code>L</code>)</p>\n\n<blockquote>\n  <p>Lazy unmount. Detach the filesystem\n  from the filesystem hierarchy now, and\n  cleanup all references to the\n  filesystem as soon as it is not busy\n  anymore.  (Requires kernel 2.4.11 or\n  later.)</p>\n</blockquote>\n"}, {'answer_id': 12945984, 'author': 'jnice', 'author_id': 1754934, 'author_profile': 'https://Stackoverflow.com/users/1754934', 'pm_score': 3, 'selected': False, 'text': '<p>I had this issue for a day until I found the real resolution. Instead of trying to force unmount an smb share that is hung, mount the share with the "soft" option. If a process attempts to connect to the share that is not available it will stop trying after a certain amount of time.</p>\n\n<blockquote>\n  <p>soft    Make the mount soft.  Fail file system calls after a number of seconds.</p>\n</blockquote>\n\n<pre><code>mount -t smbfs -o soft //username@server/share /users/username/smb/share\n\nstat /users/username/smb/share/file\nstat: /users/username/smb/share/file: stat: Operation timed out\n</code></pre>\n\n<p>May not be a real answer to your question but it is a solution to the problem</p>\n'}, {'answer_id': 17128821, 'author': 'ivanlan', 'author_id': 2489809, 'author_profile': 'https://Stackoverflow.com/users/2489809', 'pm_score': 6, 'selected': False, 'text': '<p><code>umount -a -t cifs -l</code></p>\n\n<p>worked like a charm for me on CentOS 6.3.  It saved me a server reboot.</p>\n'}, {'answer_id': 21489953, 'author': 'Phil Johnson', 'author_id': 3258894, 'author_profile': 'https://Stackoverflow.com/users/3258894', 'pm_score': 4, 'selected': False, 'text': '<p>This works for me (Ubuntu 13.10 Desktop to an Ubuntu 14.04 Server) :-</p>\n\n<pre><code> sudo umount -f /mnt/my_share\n</code></pre>\n\n<p>Mounted with </p>\n\n<pre><code> sudo mount -t cifs -o username=me,password=mine //192.168.0.111/serv_share /mnt/my_share\n</code></pre>\n\n<p>where serv_share is that set up and pointed to in the smb.conf file.</p>\n'}, {'answer_id': 23168749, 'author': 'Benedikt Köppel', 'author_id': 1067124, 'author_profile': 'https://Stackoverflow.com/users/1067124', 'pm_score': 2, 'selected': False, 'text': '<p>I had a very similar problem with davfs. In the man page of <code>umount.davfs</code>, I found that the        <code>-f -l -n -r -v</code> options are ignored by <code>umount.davfs</code>. To force-unmount my davfs mount, I had to use <code>umount -i -f -l /media/davmount</code>.</p>\n'}, {'answer_id': 26286465, 'author': 'Andy Fraley', 'author_id': 866057, 'author_profile': 'https://Stackoverflow.com/users/866057', 'pm_score': 4, 'selected': False, 'text': '<p>On RHEL 6 this worked:</p>\n\n<pre><code>umount -f -a -t cifs -l \n</code></pre>\n'}, {'answer_id': 27376945, 'author': 'chataros', 'author_id': 457250, 'author_profile': 'https://Stackoverflow.com/users/457250', 'pm_score': -1, 'selected': False, 'text': '<p>On RHEL 6 this worked for me also:</p>\n\n<p>umount -f -a -t cifs -l FOLDER_NAME</p>\n'}, {'answer_id': 28272031, 'author': 'zhjb7', 'author_id': 4518793, 'author_profile': 'https://Stackoverflow.com/users/4518793', 'pm_score': 1, 'selected': False, 'text': '<pre><code>umount -f -t cifs -l /mnt &amp;\n</code></pre>\n\n<p>Be careful of <code>&amp;</code>, let <code>umount</code> run in background.\n<code>umount</code> will detach filesystem first, so you will find nothing abount <code>/mnt</code>. If you run <code>df</code> command, then it will <code>umount /mnt</code> forcibly. </p>\n'}, {'answer_id': 29678826, 'author': 'JimmyPheonix', 'author_id': 4797231, 'author_profile': 'https://Stackoverflow.com/users/4797231', 'pm_score': -1, 'selected': False, 'text': '<p>A lazy unmount will do the job for you.</p>\n\n<pre><code>umount -l &lt;mount path&gt;\n</code></pre>\n'}, {'answer_id': 73278742, 'author': 'mgutt', 'author_id': 318765, 'author_profile': 'https://Stackoverflow.com/users/318765', 'pm_score': 0, 'selected': False, 'text': '<p>I experienced very different results regarding unmounting a dead cifs mount and found several tricks to bypass the problem temporarily.</p>\n<p>Let\'s start with the <code>mountpoint</code> command. It can be useful to analyze the status of a mount:</p>\n<pre><code>mountpoint /mnt/smb_share\n</code></pre>\n<p>Usually it returns <code>is a mountpoint</code> or <code>/ is not a mountpoint</code>.</p>\n<p>But it can even return:</p>\n<ul>\n<li>No such device</li>\n<li>Transport endpoint is not connected</li>\n<li>&lt;nothing / stale&gt;</li>\n</ul>\n<p>For every result expect of <code>is not a mountpoint</code> there is a chance of unmounting.</p>\n<p>You could try the usual way:</p>\n<p><code>umount /mnt/smb_share</code></p>\n<p>or force mode:</p>\n<p><code>umount /mnt/smb_share -f</code></p>\n<p>But often the force does not help. It simply returns the same nasty <code>device is busy</code> message.</p>\n<p>Then the only option is to use the lazy mode:</p>\n<p><code>umount /mnt/smb_share -l</code></p>\n<p>BUT: This does not unmount anything. It only &quot;moves&quot; the mount to the root of the system, which can be seen as follows:</p>\n<pre><code># lsof | grep mount | grep cwd\nmount.cif  3125             root  cwd   unknown                                          / (stat: No such device)\nmount.cif  3150             root  cwd   unknown                                          / (stat: No such device)\n</code></pre>\n<p>It is even noted in the documentation:</p>\n<blockquote>\n<p>Lazy unmount. Detach the filesystem from the file hierarchy\nnow, and clean up all references to this filesystem as soon\nas it is not busy anymore.</p>\n</blockquote>\n<p>Now if you are unlucky, it will stay there forever. Even killing the process probably does not help:</p>\n<p><code>kill -9 $pid</code></p>\n<p>But why is this a problem? Because <code>mount /mnt/smb_share</code> does not work until the lazy unmounted path is really cleaned up by the Linux Kernel. And this is even mentioned in the documentation of <code>umount</code>. &quot;lazy&quot; should only be used to avoid a long shutdown / reboot times:</p>\n<blockquote>\n<p>A system reboot would be expected in near future if you’re\ngoing to use this option for network filesystem or local\nfilesystem with submounts. The recommended use-case for\numount -l is to prevent hangs on shutdown due to an\nunreachable network share where a normal umount will hang due\nto a downed server or a network partition. Remounts of the\nshare will not be possible.</p>\n</blockquote>\n<p><strong>Workarounds</strong></p>\n<p><strong>Use a different SMB version</strong></p>\n<p>If you still have hopes that the lazy unmounted path will ever be not busy anymore and cleaned up by the Linux Kernel or you can\'t reboot at the moment, then you are maybe lucky and your SMB server supports different protocol versions. By that we can use the following trick:</p>\n<p>Lets say you mounted your share as follows:</p>\n<pre><code>mount.cifs //smb.server/share /mnt/smb_share -o username=smb_user,password=smb_pw\n</code></pre>\n<p>By that Linux automatically tries the maximum support SMB protocol version. Maybe 3.1. Now, you can force this version and it won\'t mount as expected:</p>\n<pre><code>mount.cifs //smb.server/share /mnt/smb_share -o username=smb_user,password=smb_pw,vers=3.1\n</code></pre>\n<p>But then simply try a different version:</p>\n<pre><code>mount.cifs //smb.server/share /mnt/smb_share -o username=smb_user,password=smb_pw,vers=3.0\n</code></pre>\n<p>or maybe 2.1:</p>\n<pre><code>mount.cifs //smb.server/share /mnt/smb_share -o username=smb_user,password=smb_pw,vers=2.1\n</code></pre>\n<p><strong>Change the IP of the SMB server</strong></p>\n<p>If you are able to change the IP address or add a second IP to your SMB server, you can use this to mount the same server.</p>\n<p><strong>Dirty: Forward the traffic</strong></p>\n<p>Lets say the SMB server has the IP address 10.0.0.1 and the mount is really dead. Then create this <code>iptables</code> rule:</p>\n<pre><code>iptables -t nat -A OUTPUT -d 10.0.0.250 -j DNAT --to-destination 10.0.0.1\n</code></pre>\n<p>Now change your mount rule accordingly, so it mounts the samba server through IP 10.0.0.250 instead of 10.0.0.1 and voila, its mounted without server reboot. Dirty, but it works. PS <a href="https://superuser.com/a/681707/129262">This rule does not survive a reboot</a>, so you should mount the SMB server manually and leave the <code>/etc/fstab</code> as usual.</p>\n<p><strong>More debugging</strong></p>\n<p>If you want to check if samba connection itself is theoretically working, you could try to list all SMB shares of the server through SMB3 as follows:</p>\n<pre><code>smbclient //smb.server -U &quot;smb_user&quot; -m SMB3 -L\n</code></pre>\n<p>or to view the content of a share with SMB1:</p>\n<pre><code>smbclient //smb.server -U &quot;smb_user&quot; -m NT1 -c ls\n</code></pre>\n'}, {'answer_id': 73978769, 'author': 'Aliceisnt', 'author_id': 10095447, 'author_profile': 'https://Stackoverflow.com/users/10095447', 'pm_score': 0, 'selected': False, 'text': "<p>Approaching this problem sideways:</p>\n<p>If you can't unmount because the filesystem is busy, is your ssh/terminal session cd'd into the mount directory, therefore making the filesystem busy?</p>\n<p>For me, the solution was to cd into my home, then sudo umount worked flawlessly.</p>\n<pre><code>cd ~\numount /path/to/my/share\n</code></pre>\n<p>I would post this as a comment, but I have insufficient reputation. Hoping to spare someone else the forehead slap.</p>\n"}]
['https://Stackoverflow.com/questions/74626', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/10168/']