When working with loop devices in Linux, you might encounter a frustrating situation where umount reports the device is busy, yet lsof shows no open files. This typically happens when kernel processes or other low-level system activities maintain references to the mount point.

Instead of just checking open files with lsof, we need deeper system inspection tools:

# Check for mount references
mount | grep /mnt/point

# Find processes using the mount
sudo fuser -vm /mnt/point

# Alternative to lsof with more details
sudo lsof +f -- /mnt/point

The most frequent invisible blockers include:

• Shell maintaining current directory in the mount
• Kernel threads holding references
• NFS or other network filesystem interactions
• Device mapper or LVM activities

When standard approaches fail, try these methods:

# Lazy unmount (disconnect from filesystem)
sudo umount -l /mnt/point

# Force unmount (risky)
sudo umount -f /mnt/point

# Alternative method through losetup
sudo losetup -d /dev/loopX

To avoid this situation in the future:

# Use explicit loop device allocation
sudo losetup -fP myimage.img
sudo mount /dev/loopXp1 /mnt/point

# Cleanup properly after use
sudo umount /mnt/point
sudo losetup -d /dev/loopX

For persistent cases, examine kernel references:

# Check dentry and inode references
cat /proc/mounts | grep /mnt/point

# View mount namespace information
lsns -p $$ | grep mnt

You've mounted a filesystem image using mount -o loop, but when trying to unmount it with umount, you get the frustrating "device is busy" error. Running lsof | grep /path/to/image shows nothing, leaving you scratching your head. Let's dive into why this happens and how to properly unmount stubborn loop devices.

The "device is busy" message can be misleading. While lsof checks for open files, there are other ways a device can be busy:

# Common causes:
1. A process has its working directory inside the mount
2. Kernel threads or services accessing the device
3. NFS or other network filesystem references
4. Mount points within the mount (nested mounts)

Instead of just lsof, try these more comprehensive commands:

# Find processes with working directories in the mount
sudo lsof +D /mount/point

# Check all open files on the system
sudo lsof | grep '/mount/point'

# Find processes using the block device directly
lsblk -o NAME,MAJ:MIN,RM,SIZE,RO,FSTYPE,MOUNTPOINT
sudo fuser -vm /mount/point

If you're certain nothing important is using the mount, you can force unmount:

# Lazy unmount (unmount when not busy)
sudo umount -l /mount/point

# Force unmount (more aggressive)
sudo umount -f /mount/point

Warning: Force unmounting can cause data loss if writes are in progress.

Sometimes it's easier to work with the loop device directly:

# Find which loop device is associated
losetup -a | grep '/path/to/image'

# Output looks like: /dev/loop0: []: (/path/to/image)
# Then detach it
sudo losetup -d /dev/loop0

When writing scripts that use loop devices, include cleanup:

#!/bin/bash

IMAGE="disk.img"
MOUNTPOINT="/mnt/disk"

# Mount with explicit loop device
LOOPDEV=$(sudo losetup -f)
sudo losetup $LOOPDEV $IMAGE
sudo mount $LOOPDEV $MOUNTPOINT

# Your operations here...

# Cleanup
sudo umount $MOUNTPOINT || sudo umount -l $MOUNTPOINT
sudo losetup -d $LOOPDEV

In extreme cases where the mount is completely stuck (sometimes happens with NFS or kernel issues), a reboot may be the only solution. Before rebooting, document your setup so you can reproduce and debug later.