<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  
  
  <channel>
    <title>chrisjrob: file</title>
    <link>https://chrisjrob.com</link>
    <atom:link href="https://chrisjrob.com/tag/file/feed/index.xml" rel="self" type="application/rss+xml" />
    <description>GNU Linux, Perl and FLOSS</description>
    <language>en-gb</language>
    <pubDate>Fri, 13 Feb 2026 17:22:31 +0000</pubDate>
    <lastBuildDate>Fri, 13 Feb 2026 17:22:31 +0000</lastBuildDate>
    
    <item>
      <title>Howto | Unmount a share which fails</title>
      <link>https://chrisjrob.com/2009/03/21/unmount-a-share-which-fails/</link>
      <pubDate>Sat, 21 Mar 2009 06:23:50 +0000</pubDate>
      <author>chrisjrob@gmail.com (Chris Roberts)</author>
      <guid>https://chrisjrob.com/2009/03/21/unmount-a-share-which-fails</guid>
      <description>
       <![CDATA[
         
         <p>Unmounting a share fails with error message:</p>

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Could not unmount &lt;PATH&gt;: Device or resource busy
</code></pre></div></div>

<p>First of all, check that you are not accessing any directory or file of the share with any program, or on any screen. 
If this isn’t the case, you might have encountered a problem, that is known but not related to Smb4K. It seems that under certain circumstances (that we could not figure out exactly) kdeinit background processes access files and/or directories of the share and keep them open (KDE &lt; 3.4). Unmounting is not possible unless you send…</p>

<!--more-->

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ kill -HUP PID
</code></pre></div></div>

<p>… to each kdeinit instance that has access to the share or its files. Replace PID by the pid of the kdeinit instance. You can find it out by using e. g. KSysguard.</p>


       ]]>
      </description>
    </item>
    
  </channel> 
</rss>
