Linux mount device or resource busy

umount: device is busy. Why?

The filesystem is huge, so lsof +D /path is not a realistic option. lsof /path , lsof +f — /path , and fuser /path all return nothing. fuser -v /path gives:

 USER PID ACCESS COMMAND /path: root kernel mount /path 

which is normal for all unused mounted file systems. umount -l and umount -f is not good enough for my situation. How do I figure out why the kernel thinks this filesystem is busy?

For umount —force will try harder to unmount and -v or -vvv even will reaveal more what is the problem with mount. So try: umount -vvv —force /babdmount

@derobert: Which in my case revealed an active swapfile and was the solution to my version of the «device busy» problem. Thank you!

15 Answers 15

It seems the cause for my issue was the nfs-kernel-server was exporting the directory. The nfs-kernel-server probably goes behind the normal open files and thus is not listed by lsof and fuser .

When I stopped the nfs-kernel-server I could umount the directory.

Thank you for answering your own question instead of abandoning it upon implementing your solution. Your answer helped me sort out a similarly exported NFS share.

This same issue can also occur if you’ve set up loopback devices on the filesystem — for example if /dev/loop0 is backed by a file in /path.

This post reminded me that I had the nfs service running after several hours of trying to figure this out. In RHEL6/CentOS6, use sudo service nfs stop and you may (not) need to also do sudo exportfs -u to unexport. Remember to then sudo exportfs -r and sudo service nfs start to re-export and restart the service.

To add to BruceCran’s comment above, the cause for my manifestation of this problem just now was a stale loopback mount. I’d already checked the output of fuser -vm / lsof +D , mount and cat /proc/mounts , checked whether some old nfs-kernel-server was running, turned off quotas, attempted (but failed) a umount -f and all but resigned myself to abandoning 924 days’ uptime before finally checking the output of losetup and finding two stale configured-but-not-mounted loopbacks:

parsley:/mnt# cat /proc/mounts rootfs / rootfs rw 0 0 none /sys sysfs rw,nosuid,nodev,noexec 0 0 none /proc proc rw,nosuid,nodev,noexec 0 0 udev /dev tmpfs rw,size=10240k,mode=755 0 0 /dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0 usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0 fusectl /sys/fs/fuse/connections fusectl rw 0 0 /dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0 

parsley:/mnt# fuser -vm /mnt/big/ parsley:/mnt# lsof +D big parsley:/mnt# umount -f /mnt/big/ umount2: Device or resource busy umount: /mnt/big: device is busy umount2: Device or resource busy umount: /mnt/big: device is busy parsley:/mnt# losetup -a /dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2) /dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2) parsley:/mnt# losetup -d /dev/loop0 parsley:/mnt# losetup -d /dev/loop1 parsley:/mnt# losetup -a parsley:/mnt# umount big/ parsley:/mnt# 

A Gentoo forum post also lists swapfiles as a potential culprit; although swapping to files is probably pretty rare these days, it can’t hurt to check the output of cat /proc/swaps . I’m not sure whether quotas could ever prevent an unmount — I was clutching at straws.

Источник

NFS mount: Device or resource busy

I referred the following link, the solution works. How to get over «device or resource busy»? The above solution works when you are manually deleting the file. But I have a python script that deletes the files (automated process). Sometimes I get «Device or resource busy error» when the script tries to delete the files. Consequently, my script fails. I don’t know how to resolve this issue using my python script. EDIT: The script downloads the logs files from a log server. These files are then processed by my script. After the processing is done, the script deletes these log files. I don’t think that there is anything wrong with the design. Exact Error:

OSError: [Errno 16] Device or resource busy: '/home/johndoe/qwerty/.nfs000000000471494300000944' 

What do you want to do with the processes that have the file(s) open? In the manual solution you’ve linked, you can look at what they are and decide if you want to kill them. For a script, I’d recommend against indiscriminately killing processes, for hopefully obvious reasons. In other words, why do you need to resolve this in your script?

The script creates a bunch of files and later on it deletes them. As the entire process is automated, I want to delete the file automatically. Moreover, this script is a scheduled job run by a cron.

I’ll take a bet that this problem could/should be solved at a higher level of abstraction. 🙂 Why make the files if you’re just going to delete them? Could you perhaps use memory for that (i.e. data structures)? In a shell script (not Python), the answer would be «pipelines.» Also relevant: unix.stackexchange.com/q/254296/135943

1 Answer 1

These files are NFS placeholders:

/home/johndoe/qwerty/.nfs000000000471494300000944 

Some background

In a typical UNIX filesystem, a file that is currently in use and open can be deleted but its contents will not actually disappear until the last filehandle to it is closed. You can see this in action with code like this:

$ ps -ef >/tmp/temporaryfile $ ls -l /tmp/temporaryfile -rw-r--r-- 1 roaima roaima 6758 Mar 2 14:02 /tmp/temporaryfile $ ( sleep 60 ; cat ) 

$ ps -ef > /var/autofs/net/nfsserver/tmp/temporaryfile $ ls -l /var/autofs/net/nfsserver/tmp/temporaryfile -rw-r--r-- 1 roaima roaima 6766 Mar 2 14:14 /var/autofs/net/nfsserver/tmp/temporaryfile $ ( sleep 60 ; cat )