Block Storage Volume Detachment Fails? 3 Fixes That Actually Work

Quick Answer (for advanced users)

Run sudo fuser -km /mount/point && sudo umount /mount/point to kill processes using the volume, then unmount. If that fails, use sudo lsof | grep /mount/point to find the specific process and kill it manually.

Why Volume Detachment Fails

I see this at least once a month with small business clients. You're trying to detach a block storage volume—like an AWS EBS volume or a GCP persistent disk—from a Linux instance, and you get something like Error detaching volume: device or resource busy. The cloud console shows the volume stuck in 'detaching' state for hours. The main cause? A process on the instance is still accessing the volume. Maybe it's a database (MySQL, PostgreSQL), a log writer, or even a file manager that left a handle open. I had a client last month whose entire print queue died because a cron job was writing to a mounted volume that wouldn't detach. The fix is straightforward, but you have to be careful not to corrupt data.

Fix 1: Force Unmount and Kill Processes

This is the first thing I try. It works 90% of the time.

1. SSH into the instance. Make sure you have root or sudo access.
2. Find the mount point. Run df -h | grep /mount/point to confirm where the volume is mounted. I usually check /mnt or /data.
3. Kill processes using the volume. sudo fuser -km /mount/point sends SIGKILL to all processes accessing that path. It's aggressive, but it works. For example, if your mount point is /data, run sudo fuser -km /data.
4. Unmount the volume. sudo umount /mount/point. If it still complains, try sudo umount -l /mount/point (lazy unmount). That detaches it from the filesystem, but open processes might still write—so only use it if you're sure nothing critical is running.
5. Detach the volume from the cloud console. Go to AWS EC2 > Volumes, or GCP Compute Engine > Disks, and detach it. Should work now.

If fuser isn't installed (it's on most Linux distros), install it with sudo apt install psmisc (Debian/Ubuntu) or sudo yum install psmisc (RHEL/CentOS).

Fix 2: Identify and Kill the Specific Process

Sometimes fuser kills everything, including important services. If you want more control, find the exact process.

1. List open files on the mount. Run sudo lsof | grep /mount/point. Look for the COMMAND and PID columns. For example, you might see mysqld 1234 root 4u REG 8,1 0 456 /data/mysql/test.db.
2. Kill that specific process. sudo kill -9 1234. Replace 1234 with the actual PID.
3. Unmount and detach. Same as Fix 1 steps 4 and 5.

This is safer because you only stop the process that's blocking the volume. I use this when the volume is hosting a database I want to restart after detachment.

Fix 3: Force Detach from Cloud Console (Last Resort)

If both above fail—maybe the instance is unreachable or the OS is locked up—you can force detach from the cloud provider's console. This is risky because it can corrupt the filesystem, so only do it if you have a backup.

1. AWS: Go to EC2 > Volumes, select the volume, Actions > Force Detach Volume. Confirm.
2. GCP: Go to Compute Engine > Disks, select the disk, click Detach, check the box for 'Force detach'. Confirm.
3. Azure: Go to Virtual Machines > Disks, click the disk, then 'Detach'. Azure doesn't have a force option—you'll need to stop the VM first.

After force detach, you might need to run fsck on the volume before reattaching. sudo fsck /dev/xvdf (replace with your device name). I've seen corrupted databases from force detach, so again—backup first.

Prevention Tips

To avoid this mess in the future:

• Stop services before detaching. If you know you'll detach a volume, stop MySQL, Apache, or any service that writes to it. sudo systemctl stop mysql.
• Use a script. I wrote a simple one-liner: sudo fuser -km /data; sudo umount /data; aws ec2 detach-volume --volume-id vol-xxx. It's saved me hours.
• Check with an automated tool. Tools like lsof can be run in a cron job to alert you if a volume is stuck. For example, */5 * * * * /usr/bin/lsof | grep /data > /dev/null || echo "Volume free".
• Backup before operation. This is common sense but often skipped. Snapshot the volume before detachment. On AWS: aws ec2 create-snapshot --volume-id vol-xxx. On GCP: gcloud compute disks snapshot DISK_NAME.

That's it. Next time your volume is stuck, you'll know exactly what to do. No need to wait for support tickets or reboot the instance.