“Device or resource busy”错误完全解决指南：当Linux拒绝卸载设备时-Vc博客

在Linux系统管理中，”Device or resource busy”是卸载存储设备或删除文件时最常见的错误之一。本文通过真实的故障场景，深入分析进程占用、文件系统挂载、内核模块依赖等根本原因，提供从快速定位到彻底解决的完整方案，帮助系统管理员高效解决资源占用问题。

一、故障现场：无法卸载的存储设备

某次系统维护中，尝试卸载数据盘时遭遇阻碍：

# 尝试卸载数据分区
umount /data
# 输出：umount: /data: target is busy.

# 强制卸载也失败
umount -f /data
# 输出：umount: /data: target is busy.

这种错误意味着有进程正在使用该挂载点下的文件或目录，需要找到并释放这些资源。

二、快速诊断：定位资源占用源

1. 使用lsof查找占用进程

# 查找正在使用挂载点的进程
lsof +f -- /data

# 或者使用挂载点路径
lsof /data

# 更精确的查询方式
lsof | grep /data

# 输出示例：
# COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
# bash    1234 root  cwd    DIR   8,17     4096 131073 /data/project
# vim     5678 john    4u   REG   8,17    12288 131075 /data/notes.txt

2. 使用fuser命令识别进程

# 查看哪些进程正在使用挂载点
fuser -v /data

# 输出示例：
#                  USER        PID ACCESS COMMAND
# /data:           root       1234 ..c.. bash
#                  john       5678 ...c. vim

# 显示详细的访问模式
fuser -vm /data

# 查看具体的文件访问类型
fuser -v -m /data

3. 自动化诊断脚本

<strong>#!/bin/bash</strong><br># resource_busy_diagnosis.sh<br><br>MOUNT_POINT="$1"<br><br>if [ -z "$MOUNT_POINT" ]; then<br>    echo "使用方法: $0 <挂载点路径>"<br>    exit 1<br>fi<br><br>echo "====== 资源占用诊断报告: $MOUNT_POINT ======"<br>echo "诊断时间: $(date)"<br>echo<br><br># 1. 检查挂载状态<br>echo "1. 挂载状态检查:"<br>mount | grep "$MOUNT_POINT"<br>echo<br><br># 2. 使用lsof分析<br>echo "2. 进程占用分析 (lsof):"<br>lsof +f -- "$MOUNT_POINT" <strong>2</strong>>/dev/null | head -20<br>echo<br><br># 3. 使用fuser分析<br>echo "3. 进程占用分析 (fuser):"<br>fuser -v "$MOUNT_POINT" <strong>2</strong>>/dev/null<br>echo<br><br># 4. 查找打开的文件描述符<br>echo "4. 打开文件分析:"<br>for pid in $(fuser "$MOUNT_POINT" <strong>2</strong>>/dev/null); do<br>    if [ -d "/proc/$pid" ]; then<br>        echo "进程 $pid: $(ps -p $pid -o comm=)"<br>        ls -la "/proc/$pid/fd" <strong>2</strong>>/dev/null | grep "$MOUNT_POINT" | head -5<br>    fi<br>done

三、常见场景与解决方案

1. 场景一：Shell会话占用

# 用户当前工作目录在挂载点内
pwd
# 输出：/data/project

# 解决方案：切换到其他目录
cd /tmp

# 或者查找所有此类会话
lsof +D /data | grep cwd

2. 场景二：文件被进程打开

# 查找打开文件的进程
lsof /data/important-file.db

# 输出：
# COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
# python  7890 app    3r   REG   8,17 104857600 131080 /data/important-file.db

# 解决方案：终止进程或关闭文件
kill -TERM 7890

# 或者更优雅的方式 - 发送信号让进程自行清理
kill -USR1 7890

3. 场景三：内核服务占用

# 检查NFS、Samba等网络文件系统
ps aux | grep -E '(nfs|samba)'

# 检查是否被容器运行时占用
docker ps --filter volume=/data
podman ps --filter volume=/data

# 检查是否被备份服务占用
ps aux | grep -E '(rsync|tar|dump)'

四、强制解除占用方案

1. 安全终止占用进程

<strong>#!/bin/bash</strong>
# safe_umount.sh

MOUNT_POINT="$1"

if [ -z "$MOUNT_POINT" ]; then
    echo "使用方法: $0 <挂载点>"
    exit 1
fi

echo "尝试安全卸载: $MOUNT_POINT"

# 1. 查找并显示占用进程
echo "当前占用进程:"
fuser -v -m "$MOUNT_POINT" <strong>2</strong>>/dev/null

# 2. 发送TERM信号终止进程
echo "终止占用进程..."
fuser -k -TERM -m "$MOUNT_POINT" <strong>2</strong>>/dev/null

# 3. 等待进程退出
sleep 3

# 4. 检查是否还有进程占用
if fuser -m "$MOUNT_POINT" <strong>2</strong>>/dev/null; then
    echo "仍有进程占用，发送KILL信号..."
    fuser -k -KILL -m "$MOUNT_POINT" <strong>2</strong>>/dev/null
fi

# 5. 尝试卸载
if umount "$MOUNT_POINT"; then
    echo "成功卸载: $MOUNT_POINT"
else
    echo "卸载失败，请手动检查"
    lsof +f -- "$MOUNT_POINT" <strong>2</strong>>/dev/null
fi

2. 延迟卸载方案

# 使用lazy卸载（适用于无法立即终止的进程）
umount -l /data

# lazy卸载的特点：
# - 立即从文件系统层次结构中解除挂载
# - 实际设备在所有进程释放文件后才会真正卸载
# - 新进程无法再访问该挂载点

五、高级排查技巧

1. 深入分析内核占用

# 查看内核模块依赖
lsmod | grep -E '(nfs|fuse|cifs)'

# 检查设备映射
dmsetup ls
dmsetup status

# 查看设备挂载栈
cat /proc/mounts | grep /data

# 检查网络文件系统连接
showmount -e localhost
smbstatus -S

2. 容器运行时占用排查

<strong>#!/bin/bash</strong>
# container_volume_check.sh

MOUNT_POINT="$1"

echo "检查容器卷占用情况..."

# Docker容器检查
echo "=== Docker容器 ==="
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Mounts}}" | grep "$MOUNT_POINT"

# 检查Docker卷
docker volume ls | while read vol; do
    if docker volume inspect $vol | grep -q "$MOUNT_POINT"; then
        echo "Docker卷占用: $vol"
    fi
done

# Podman容器检查
echo "=== Podman容器 ==="
podman ps --format "table {{.Names}}\t{{.Status}}\t{{.Mounts}}" | grep "$MOUNT_POINT"

# Kubernetes Pod检查
echo "=== Kubernetes Pods ==="
kubectl get pods --all-namespaces -o json | jq -r '.items[] | select(.spec.volumes[]?.hostPath.path == "'"$MOUNT_POINT"'") | .metadata.namespace + "/" + .metadata.name'

六、预防措施与最佳实践

1. 挂载点使用规范

# 创建专用的工作目录，避免在挂载点根目录操作
mkdir /data/work /data/temp
chmod 1777 /data/temp  # 设置sticky位

# 使用脚本规范化访问
#!/bin/bash
# safe_cd_to_mount.sh

MOUNT_POINT="/data"
WORK_DIR="/data/work/$(whoami)"

# 确保工作目录存在
mkdir -p "$WORK_DIR"

# 切换到工作目录
cd "$WORK_DIR" || exit 1

echo "现在在安全的工作目录: $PWD"
echo "要退出时请运行: safe_exit_mount"

# 创建安全退出函数
safe_exit_mount() {
    cd /tmp
    echo "已退出挂载点工作目录"
}

2. 自动监控与告警

<strong>#!/bin/bash</strong>
# mount_point_monitor.sh

CRITICAL_MOUNTS=("/data" "/archive" "/backup")
ALERT_EMAIL="admin@company.com"

for mount in "${CRITICAL_MOUNTS[@]}"; do
    # 检查挂载点是否繁忙
    if fuser -m "$mount" <strong>2</strong>>/dev/null | grep -q .; then
        # 生成报告
        report_file="/tmp/mount_busy_$(date +%Y%m%d_%H%M%S).log"
        
        {
            echo "警告: 关键挂载点 $mount 被占用"
            echo "时间: $(date)"
            echo "占用进程:"
            fuser -v -m "$mount" <strong>2</strong>>/dev/null
            echo
            echo "详细文件访问:"
            lsof +f -- "$mount" <strong>2</strong>>/dev/null
        } > "$report_file"
        
        # 发送告警
        mail -s "挂载点占用告警: $mount" "$ALERT_EMAIL" < "$report_file"
    fi
done

3. 系统服务依赖管理

# 创建系统服务停止脚本
#!/bin/bash
# stop_services_for_umount.sh

MOUNT_POINT="$1"

echo "停止依赖 $MOUNT_POINT 的服务..."

# 根据挂载点停止相关服务
case "$MOUNT_POINT" in
    "/data")
        systemctl stop apache2
        systemctl stop mysql
        systemctl stop docker
        ;;
    "/backup")
        systemctl stop backupd
        systemctl stop rsyncd
        ;;
    *)
        echo "未知的挂载点: $MOUNT_POINT"
        exit 1
        ;;
esac

echo "服务停止完成"
sleep 5

# 验证服务状态
systemctl is-active apache2 mysql docker

七、真实案例：生产环境故障解决

1. 案例背景

数据库服务器需要紧急更换硬盘，但/data分区始终显示”Device or resource busy”，即使停止数据库服务后依然如此。

2. 排查过程

# 使用详细诊断脚本
./resource_busy_diagnosis.sh /data

# 发现异常进程
lsof +f -- /data | grep deleted

# 输出：
# python 7890 app 3w REG 8,17 1048576000 131075 /data/old_logfile.log (deleted)

3. 解决方案

# 发现被删除但仍被进程占用的文件
# 解决方案：清空文件描述符

# 找到进程和文件描述符
pid=7890
fd=3

# 清空内容而不终止进程
: > /proc/$pid/fd/$fd

# 然后成功卸载
umount /data

【总结】

“Device or resource busy”错误通常源于进程文件占用、工作目录依赖或内核服务关联。通过系统化的诊断流程：lsof/fuser分析→进程管理→安全卸载，可以高效解决资源占用问题。建立规范的挂载点使用流程和监控体系，能够有效预防此类故障的发生。

1 本网站名称： VC博客
2 本站永久网址：vcvcc.cc
3 本站资源如有解压密码，则为：vcvcc.cc
4 本网站的文章部分内容可能来源于网络，仅供大家学习与参考，如有侵权，请联系站长 QQ378214732进行删除处理。
5 本站一切资源不代表本站立场，并不代表本站赞同其观点和对其真实性负责。
6 本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现请向站长举报
7 本站资源大都存储在云盘，如发现链接失效，请联系我们我们会第一时间更新。
8 如无特别声明本文即为原创文章仅代表个人观点，版权归《VC博客》所有，欢迎转载，转载请保留原文链接。

THE END