Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On linux, I have a file that I've mounted using the -o loop option. I want to unmount it. However it tells me that device is busy. However by doing lsof | grep pathofimagefile I get no results. And yet I can't unmount!

share|improve this question
up vote 3 down vote accepted

I believe this is what fuser is for. Specifically, fuser -km /path/to/mount/point

share|improve this answer
    
-k is too kill all processes using it. – Kyle Brandt Aug 26 '09 at 17:07
    
well, if you want to unmount it, that's what you gotta do, right? Hopefully people don't just cut and paste commands they see on the internet (and run them as root, and change a bogus directory path to one that's real...) – chris Aug 26 '09 at 17:44

In your question, you wrote grep pathofimagefile. Have you tried with grep pathofmountpoint?

Also verify that no process running on your machine has your mount point (or a subdirectory of it) set as its current working directory.

sudo ls -l /proc/*/cwd | grep pathofmountpoint will give you those process numbers.

share|improve this answer

Make sure you don't have an open shell thats in the mounted directory. I've never looked to see if that shows in lsof or not. Also when doing your lsof try greping on the mount point not the image file itself.

share|improve this answer

Wow, this is really old, but to benefit those finding this in the future, here is what I found -- I had nested mounts. That is, I mounted a root filesystem image with a loopback device on /mnt. Under that mount point I had then mounted proc and sysfs filesystems mounted under /mnt/proc and /mnt/sys. Later I had forgotten about the proc and sysfs filesystems when trying to umount the filesystem image.

# mount -o loop rootfs_disk.img /mnt
# mount proc /mnt/proc -t proc
# mount sysfs /mnt/sys -t sysfs
# # ... ages pass
# umount rootfs_disk.img
umount: /mnt: device is busy.
# umount /mnt
umount: /mnt: device is busy.

-- Noah Spurrier

share|improve this answer

run pwd ... is your terminal still sitting in the pathofimagefile? If so move out of the pathofimagefile and then re-execute umount.

share|improve this answer
    
I thought of that, and no, it's not. I've been stuck with that before. But that would show up in lsof – Rory Aug 26 '09 at 21:09

What about:

sudo lsof | grep loop
share|improve this answer
    
Nevermind, this just shows the kernel process – Kyle Brandt Aug 26 '09 at 17:07

I had the same problem. The directory was not only mounted with -o loop, but it was being exported to NFS using the exportfs command. fuser and lsof both said the device was not in use. Also, the exportfs -u had no complaints. However, NFS was still showing the device in /proc/fs/nfs/exports. I restarted nfs and got this:

Shutting down NFS mountd:                                  [  OK  ]
Shutting down NFS daemon:                                  [  OK  ]
Shutting down NFS services:                                [FAILED]
Starting NFS services:                                     [  OK  ]
Starting NFS quotas:                                       [  OK  ]
Starting NFS daemon:                                       [  OK  ]
Starting NFS mountd:                                       [  OK  ]

Then, I could umount the devices. Unfortunately, it's quite difficult to reproduce. Maybe someone can give more insights.

share|improve this answer

I had just now the same problem, umount won't unmount my loop-device. Strange enough, that neither lsof nor fuser could find any process using that mountpoint. lsof only found the [loop0] kernel-thread, I tried to kill it (even with -9) but no success.

What really wondered me, was that after waiting a few minutes (after trying umount -f /mnt etc. - did not work), I tried it again, and voila, now it worked?!

I´m not sure, but maybe that the kernel itself couldn't free the loop0-thread for a while, but later it could close it? Who knows...

So the bottom line is: try that umount over and over again, after a certain time you could have luck :-)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.