-
Archives
- February 2010
- October 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- November 2007
- October 2007
- September 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- March 2005
- February 2005
- January 2005
- December 2004
- November 2004
- October 2004
- September 2004
- August 2004
- July 2004
- June 2004
- May 2004
- April 2004
- March 2004
- February 2004
-
Meta
Daily Archives: January 5, 2005
Umnounting a Stubborn Share
In order to make sure one of my current projects gets backed up regularly, I keep the files on a server that I mount using samba so that I can access the files as if they’re on my system. This is easier than finding a way to back up my system because I can force the system to mount the share at boot and never have to think about saving the files out (well, except that I’m paranoid and am also keeping versions in CVS [no, not the drug store -- it's a computer dork thing]). Occasionally, samba mounts go haywire, though, and when this happens, you can often un- and remount them to solve the problem.
When I tried this today, I got a “device is busy” error and couldn’t unmount the share even when I tried to force it. I googled for a minute and found this site, which pointed me in the right direction. Although I had checked all my terminals to verify that my cwd wasn’t on the share in question, I thought it’d be good to check and see if there was somehow somebody (me or someone else) using the share. And it turns out that the fuser command allows you to see this sort of info:
[houston]# fuser -vmu /home/files
USER PID ACCESS COMMAND
/home/files root 1553 ..c.. su
houston 9046 ..c.. bash
The “c” beside these entries means that the file system is in question is the cwd for that process. So in these cases, I was in /home/files when I opened a new session (in one case an su and in another a whole other terminal session) from which I then changed directories (meaning that it wasn’t obvious to me that I was actually using the file system because pwd showed me being elsewhere). Once I killed the processes, I was able to unmount the share, and when I remounted, the flakiness was gone. Nifty. Continue reading