Ubuntu error unmounting

Sometimes when you unmount a filesystem or drive, the system shows «unmount target is busy» message. Unless you release the busy system, you won’t be able to unmount.

In this guide, we learn how to fix umount target is busy in Linux.

What is unmount target busy

A mounted filesystem can be accessed by any process running on the Linux operating system. When such a filesystem or a directory which is being accessed by some process is unmounted, the system may issue the target as busy (“device is busy”). One of the reasons the system doesn’t allow unmount is to prevent data loss.

This problem generally occurs in the following scenarios:

1. The current working directory accessed by the terminal is on the path of the mount point
2. A process is accessing the files on the filesystem hierarchy being unmounted
3. A process is accessing a file which relies (reads/writes) on the file inside the filesystem which is being unmounted.
4. Remote mount point unreachable

Force unmount

Force unmount is one solution to detach the busy device.

Usually, you see a busy device message when you try to unmount an NFS filesystem. This happens often when the NFS server has some issues (mainly unreachable) and you have a soft NFS mount.

Force unmount will detach the server mount point by disrupting some running processes.

CAUTION: This may cause data loss or corrupt files or programs accessing file throw errors.

unmount -f /path/to/busy-nfs-mount

You can verify if it is successfully unmounted using the df command.

Using lsof — Find and Kill the processes using the file

The lsof (list open files) command displays a list of all open files and the processes associated with them on a specific file system, directory, or device. By default, it lists all files, shared libraries, and directories that are currently open and provides as much information as possible about each of them.

We can use lsof command to find PID (process id) corresponding to our mount point and then kill that process.

Use the following lsof command to list processes using the mount point.

lsof /media/dsk
or
lsof  | grep '/media/dsk'

The output shows that the user linuxopsys has two bash processes with PIDs 4255 and 4335 using /media/dsk. 

Once these two programs are stopped the device is no longer busy.

Once you make sure its safe to kill the process, run the following kill command:

kill -9 4255
kill -9 4335

If no more processes tide to the mount point, you initiate umount command.

Using fuser —  Kill processes accessing the file

fuser command in Linux helps to identify the processes which are accessing sockets or files on filesystems.

Use fuser command with -m option which lists all the processes accessing the files or mount point on the file system. You can add -v option for verbose.

The following example displays all the processes accessing the file system /media/dsk along with their process ids arranged in a tabular format.

fuser -mv /media/dsk

Now you found the processes which are using the file on the mounted filesystem. You can use kill command to terminate those processes.

You can add -k option to kill processes in a single command, so you can avoid one step.

fuser -kmv /media/dsk

Lazy unmount

Lazy unmounting is used to unmount the mount point from the Linux filesystem hierarchy. The command removes all references to the detached file system as soon as it is no longer busy. Once no processes are accessing the unmounted file system, the umount command executes and actually detaches the file system. 

Lazy unmounting a mount point is beneficial when we don’t want to unexpectedly kill the process which are accessing the file systems as this may lead to loss of data or may corrupt the file systems. 

For example, when you are copying a file from the mounted flash drive to linux machine and need to unmount the mounted device at the same time so that you don’t need to actively check the status of the file transfer, you can execute a lazy unmount on the flash drive so that once the operation to copy the file is complete, the system automatically detaches the mount point of the flash drive.

To lazy unmount use -l option followed by the mount path:

umount -l <path_to_mount_point>

Conclusion

In this guide, we learned how to fix when you encounter umount target is busy in Linux. We have explained solutions using force unmount, detaching busy device by finding and kill the processes, and finally lazy mount.

Thanks for reading, please leave your feedback and suggestions in the comment section.

[sudo] пароль для valet:         
root@pc-78:~# fdisk -l
Диск /dev/loop0: 55,3 MiB, 58007552 байт, 113296 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт


Диск /dev/loop1: 290,4 MiB, 304545792 байт, 594816 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт


Диск /dev/loop2: 30,3 MiB, 31735808 байт, 61984 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт


Диск /dev/loop3: 31 MiB, 32432128 байт, 63344 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт


Диск /dev/sda: 465,8 GiB, 500107862016 байт, 976773168 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: dos
Идентификатор диска: 0xb389be3d

Устр-во    Загрузочный    начало     Конец   Секторы Размер Идентификатор Тип
/dev/sda2  *             1050624   2101247   1050624   513M             b W95 FA
/dev/sda3                2103294 975722495 973619202 464,3G             5 Расшир
/dev/sda4              975722496 976771071   1048576   512M             b W95 FA
/dev/sda5                2103296 975722495 973619200 464,3G            83 Linux

Раздел 3 начинается не на границе физического сектора.
Элементы таблицы разделов упорядочены не так, как на диске.
root@pc-78:~# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0    7:0    0  55,3M  1 loop /snap/core18/1885
loop1    7:1    0 290,4M  1 loop /snap/vlc/1700
loop2    7:2    0  30,3M  1 loop /snap/snapd/9279
loop3    7:3    0    31M  1 loop /snap/snapd/9607
sda      8:0    0 465,8G  0 disk 
├─sda2   8:2    0   513M  0 part 
├─sda3   8:3    0     1K  0 part 
├─sda4   8:4    0   512M  0 part 
└─sda5   8:5    0 464,3G  0 part /
root@pc-78:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda6 during installation
UUID=ab2fdc9d-920b-424c-a2c5-75ca5a85de92 /               ext4    errors=remount-ro 0       1
/swapfile                                 none            swap    sw              0       0
root@pc-78:~# df -hT
Файл.система   Тип      Размер Использовано  Дост Использовано% Cмонтировано в
udev           devtmpfs   2,9G            0  2,9G            0% /dev
tmpfs          tmpfs      582M         1,4M  581M            1% /run
/dev/sda5      ext4       456G          68G  368G           16% /
tmpfs          tmpfs      2,9G          41M  2,9G            2% /dev/shm
tmpfs          tmpfs      5,0M         4,0K  5,0M            1% /run/lock
tmpfs          tmpfs      2,9G            0  2,9G            0% /sys/fs/cgroup
/dev/loop0     squashfs    56M          56M     0          100% /snap/core18/1885
/dev/loop1     squashfs   291M         291M     0          100% /snap/vlc/1700
/dev/loop2     squashfs    31M          31M     0          100% /snap/snapd/9279
tmpfs          tmpfs      582M          40K  582M            1% /run/user/1000
/dev/loop3     squashfs    31M          31M     0          100% /snap/snapd/9607
root@pc-78:~# cat /proc/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=2940960k,nr_inodes=735240,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=595712k,mode=755 0 0
/dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/unified cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/rdma cgroup rw,nosuid,nodev,noexec,relatime,rdma 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=42,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12214 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/loop0 /snap/core18/1885 squashfs ro,nodev,relatime 0 0
/dev/loop1 /snap/vlc/1700 squashfs ro,nodev,relatime 0 0
/dev/loop2 /snap/snapd/9279 squashfs ro,nodev,relatime 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=595708k,mode=700,uid=1000,gid=1000 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
/dev/loop3 /snap/snapd/9607 squashfs ro,nodev,relatime 0 0
root@pc-78:~# ```

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

Avoid umount -l

At the time of writing, the top-voted answer recommends using umount -l.

umount -l is dangerous or at best unsafe. In summary:

• It doesn’t actually unmount the device, it just removes the filesystem from the namespace. Writes to open files can continue.
• It can cause btrfs filesystem corruption

Work around / alternative

The useful behaviour of umount -l is hiding the filesystem from access by absolute pathnames, thereby minimising further moutpoint usage.

This same behaviour can be achieved by mounting an empty directory with permissions 000 over the directory to be unmounted.

Then any new accesses to filenames in the below the mountpoint will hit the newly overlaid directory with zero permissions — new blockers to the unmount are thereby prevented.

First try to remount,ro

The major unmount achievement to be unlocked is the read-only remount. When you gain the remount,ro badge, you know that:

1. All pending data has been written to disk
2. All future write attempts will fail
3. The data is in a consistent state, should you need to physcially disconnect the device.

mount -o remount,ro /dev/device is guaranteed to fail if there are files open for writing, so try that straight up. You may be feeling lucky, punk!

If you are unlucky, focus only on processes with files open for writing:

lsof +f -- /dev/<devicename> | awk 'NR==1 || $4~/[0-9]+[uw -]/'

You should then be able to remount the device read-only and ensure a consistent state.

If you can’t remount read-only at this point, investigate some of the other possible causes listed here.

Read-only re-mount achievement unlocked 🔓☑

Congratulations, your data on the mountpoint is now consistent and protected from future writing.

Why fuser is inferior to lsof

Why not use use fuser earlier? Well, you could have, but fuser operates upon a directory, not a device, so if you wanted to remove the mountpoint from the file name space and still use fuser, you’d need to:

1. Temporarily duplicate the mountpoint with mount -o bind /media/hdd /mnt to another location
2. Hide the original mount point and block the namespace:

Here’s how:

null_dir=$(sudo mktemp --directory --tmpdir empty.XXXXX")
sudo chmod 000 "$null_dir"

# A request to remount,ro will fail on a `-o bind,ro` duplicate if there are
# still files open for writing on the original as each mounted instance is
# checked.  https://unix.stackexchange.com/a/386570/143394
# So, avoid remount, and bind mount instead:
sudo mount -o bind,ro "$original" "$original_duplicate"

# Don't propagate/mirror the empty directory just about hide the original
sudo mount --make-private "$original_duplicate"

# Hide the original mountpoint
sudo mount -o bind,ro "$null_dir" "$original"

You’d then have:

1. The original namespace hidden (no more files could be opened, the problem can’t get worse)
2. A duplicate bind mounted directory (as opposed to a device) on which
   to run fuser.

This is more convoluted^[1], but allows you to use:

fuser -vmMkiw <mountpoint>

which will interactively ask to kill the processes with files open for writing. Of course, you could do this without hiding the mount point at all, but the above mimicks umount -l, without any of the dangers.

The -w switch restricts to writing processes, and the -i is interactive, so after a read-only remount, if you’re it a hurry you could then use:

fuser -vmMk <mountpoint>

to kill all remaining processes with files open under the mountpoint.

Hopefully at this point, you can unmount the device. (You’ll need to run umount on the mountpoint twice if you’ve bind mounted a mode 000 directory on top.)

Or use:

fuser -vmMki <mountpoint>

to interactively kill the remaining read-only processes blocking the unmount.

Dammit, I still get target is busy!

Open files aren’t the only unmount blocker. See here and here for other causes and their remedies.

Even if you’ve got some lurking gremlin which is preventing you from fully unmounting the device, you have at least got your filesystem in a consistent state.

You can then use lsof +f -- /dev/device to list all processes with open files on the device containing the filesystem, and then kill them.

^{[1] It is less convoluted to use mount --move, but that requires mount --make-private /parent-mount-point which has implications. Basically, if the mountpoint is mounted under the / filesystem, you’d want to avoid this.}

The error umount target is busy could mean that some process has a working directory or an open filehandle underneath the mount point. This issue has many solutions, including changing the working directory, ending the offending process, or closing the filehandle before unmounting.

We take a deeper look into this error in this article, so scroll down to learn more.

What Does Umount Target Is Busy Mean?

Umount target is busy error means the problem is being passed from an underlying issue that usually originates from an open file beneath the mount point. As part of the hot network questions, this error occurs when the shell running in your console window has a directory within a file system on that device as its existing working directory.

What Are the Causes of the Error?

When you receive a device busy message, you must know that it is not a system message. Instead, it is a message passed from an underlying operating system. Majorly, it indicates one of the following scenarios:

When you receive the error message while trying to mount a directory, it indicates that there is a user at the mount point. Alternatively, it could mean the directory is already mounted.

If you get the error message umount: target is busy when trying to unmount a directory, a user or a process has an open file on that file system. Simply put, there is a working directory beneath that particular mount point.

Also note that in Linux and Unix, the system usually wants to keep a file system mounted when a process has a current working directory in the file system.

The umount device is busy NFS scenario is a bit different. While the problem could occur due to the above issues, NFS shares hosted on a machine can be the cause, especially if they are backed by the device you are trying to unmount.

Other Reasons of Target Is Busy Issue

Although the reason we talked about above is the most common, there can be other causes as well:

• Open (possibly deleted) socket
• Kernel – a different filesystem mounted on the filesystem you are trying to umount. Check using mount | grep <mountpoint>/
• NFS-kernel-server is exporting the directory (and a client mounts the directory)
• A loopback device backing file exists in the dir
• A swapfile exists in the dir
• The dir contains an umounted encfs
• The device failed

Target Is Busy Error Example

The error target is busy might occur when running umount /path, and usually, the response is:

umount: /path: device is busy

This can be disappointing if you do not know how to go about it. If you run a huge filesystem, using the lsof +D /path might not be realistic. Similarly, when you use lsof +f — /path and fuser /path, they will return nothing.

You may opt to use umount -l or umount -f, but their suitability depends on the situation. So, what could be the cause in this case?

If the shell’s current directory is on the mount point, it could be the cause. But in most cases, the fuser would point out.

Note that when NFS-kernel-server exports the directory, it might lead to this error popping up. The NFS-kernel-server goes behind the regular open files, thus, it is not listed by lsof and fuser. So try stopping the NFS-kernel-server and check if you can umount the directory.

Also, you can execute sudo service samba stop first, or sudo service NFS stop (in RHEL6/CentOS6). With these actions, you may not need to perform sudo exportfs -u to unexport. Then remember to sudo exportfs -r and Sudo service NFS start to re-export and restart the service.

If you set up a loopback device on the filesystem, you will get the busy error. For instance, if a file backs/dev/loop0 in /path.

How to Fix Umount Failure

The finest way to solve the issue is to determine the user utilizing the mounted directory. Here are some tactics to use.

– Using Operating System Commands

Use an operating system command like fuser to return a list of process IDs and user names currently using the directory mounted under the local_mount_point. Fuser will tell you which process uses a file, a directory, or a socket. Besides, it provides information about the user who owns the process alongside the type of access.

Fuser is a very comprehensive tool as it displays the process id (PID) of each process using a specified file system or files. This helps determine whether the process can be killed or whether you are forced to wait until it completes.

To determine which processes have access to your file (~.bashrc), this is how to do it:

$ fuser -v -m .bashrc

The option -m means name/list all processes that have access to the file name. If you want to kill a process, utilize the -k or –kill option as shown below:

$ sudo fuser -k

You can also interactively kill a process using -i or –interactive, as shown below:

$ sudo fuser -ki

This command works on Solaris, IRIX, HP-UX, Linux, and AIX. The example below assumes that the fuser utility is defined in your path variable.

fuser -uc /vobs/myvob

if it returns an Invalid argument error, it may mean the VOB is already unmounted. To confirm, run the command ps -ef | grep /vobs/myvob.

– Check /Vobs/Myvob

If you are using ClearCase, check whether your /vobs/myvob is the current working directory on a client host when unmounting. The current directory will throw the target busy error if it is the current directory.

The finest way out of this issue is to turn it off. It should not be the working directory on a host client when unmounting.

– Use Umount -l and Umount -f Commands.

If you continually get the busy device signal, you can detach the device immediately using these two commands. The commands let you unmount devices even if they are busy.

Nonetheless, these commands disrupt running processes, resulting in data loss or corrupted files. Applications accessing target device or NFL files generate errors or may not work correctly after the unmount.

In addition, do not run these commands while inside-mounted path (Folder/Drive/Device) itself. First, use the pwd command to validate your current directory path, then use the cd command to get out of the mounted path, i.e., to unmount it later using the above commands.

How to Safely Unmount a Busy Mount Point

Mount point busy Linux response gives a device a busy response when trying to unmount a filesystem. This is a reasonable behavior as it will help avert data loss. Typically, it disallows unmounting a filesystem when in use. Here are some ways to apply:

– Force Unmount

The unmount option allows you to disengage a device that sends busy signal at once, even if it is busy. The force umount Linux option uses:

-f, –force

Force an unmount

The -f choice is for unreachable NFS system(NFS server going down). Note that programs may not expect a force or lazy unmounting. Thus, this force unmount Linux option might disrupt the filesystem’s running processes, causing data loss or corrupt files opened.

– Kill the Processes and Then Unmount It

Use the filesystem to kill the process, making it safe to unmount. You can apply one of the following formulae:

• Isof – finds the processes accessing the filesystem. Run # lsof | grep ‘/mnt/data’ as root. If you want a much faster alternative, although not accurate, use the total list of open files and grep it
• Fuser – it also finds the processes accessing root partition or file system. The advantage of fuser is that it kills files, causing drama.

It is worth mentioning that unmounting and then remounting a device can help solve the issue. When you unmount, a file system enables you to determine whether there are problems.

– Other Approaches

Umount target is busy redhat problems can use the two approaches. However, if the offending process runs in chroot, lsof and fuser cannot find it. So, if you suspect something is still running in a chroot, use Sudo ls -l /proc/*/root | grep chroot. This is a more effective way to unmount root. You can replace “chroot” with the path to the chroot.

These solutions will help you deal with umount target is busy gparted issues. However, if you use dev/sda1, you still get the error. If you mounted it in a file manager /automount, try terminal-> Sudo unmount -l /dev/sda1. Alternatively, reboot and try not to open a file manager. But always ensure you are dealing with the correct partition from where you format it.

Conclusion

To wrap up the article, here are the checklist of the most important points that we talked in the text:

• The umount command unmounts and initially mounted the device, directory, file, or file system.
• You will get a target is busy response under different circumstances, for instance, when other directories are mounted on top of /mnt/dir.
• To check why the error occurs, you can use commands fuser (fuser -vm /mnt/dir) or lsof (lsof /mnt/dir). Run both as root because the output is limited if you run them as non-root.
• Fuser tells you processes accessing the mount point while lsof shows each open file on the mount point.

When you encounter a target busy error when mounting or unmounting a device, good practice will be to locate the source of the problem. Once you find it, you can apply the solutions outlined in this article.