Fixing ‘Umount Target is Busy’ Error in Linux
A not-so-uncommon error while using umount command is ‘target is busy’. Learn what you can do to get rid of this error.
Fixing ‘Umount Target is Busy’ Error in Linux
Unmounting disks in the Linux command line is not complicated. All you have to do is to use the umount command:
umount targetBut once in a while, you’ll come across an error that says ‘umount: target is busy’:
So how are you supposed to solve this issue?
Well, before solving this issue, let me share the reason behind this problem first.
The reason behind Umount target is busy
The reason is quite simple! The target device is still in use.
With enough permissions, any process might be utilizing that drive that you want to unmount, and to prevent data loss, the kernel won’t allow you to unmount.
How to solve Umount target is busy in Linux
If an ongoing data transfer occurs in the background, you may lose your data by forcefully unmounting your drive.
There are times when you want to unmount the drive at any cost. Perhaps the drive isn’t responding for some reason and you want to unmount it.
In this tutorial, I will share three ways to unmount the target:
- By killing the process itself
- Using force unmount
- Using the lazy unmount
Let’s start with the first method.
Method 1: Unmout target by killing the process itself (recommended)
This is the best way of unmounting the target in my opinion as you are eventually killing the process itself.
The first step is to find the PID of the process that causes the problems.
To do so, I will be using the lsof command in the following manner:
sudo lsof /Path/to/target
Once you get the PID, it’s quite simple to force kill the process:
sudo kill -9 [PID]And now, you should be able to unmount the drive easily:
Pretty neat way. Isn’t it?
Method 2: Using force unmount (for Network File Systems)
The force unmount option is mainly preferred by those who are dealing with network file systems.
So it may NOT give you the expected results with your local file system.
To use the force unmount, you will have to use the same old umount command but with the -f flag:
sudo umount -f /Path/to/target
Method 3: Using the lazy unmount (Schrödinger’s unmount)
This option does not actually unmount your target but just removes the target from the namespace. And will unmount the target when the drive is not being utilized anymore!
It is more of a Schrödinger’s mount when you can never be sure of whether the filesystem is unmounted or not!
So why am I even adding this to the solution’s list? Well, this is the least harmful way of unmounting your stubborn drive.
To use the lazy unmount, you will have to use the -l flag with the umount command as shown:
sudo umount -l /Path/to/target
And here you have it!
Which one should you choose?
In times like you have to have your drive unmounted, I would prefer going with the 1st method which involves killing the process itself.
And there is a strong reason why. It gets my job done without any hiccups.
Sure, you may want to go with either of the last two options based on your use case.
Umount Target is Busy
“In Linux, we use the umount command to unmount a device or partition as specified by its path. However, in some scenarios, you may encounter the “target is busy” error when attempting to unmount a device.
In this tutorial, we will attempt to break down the cause of this error, why it occurs, and how you can resolve it.”
Cause of “Target is Busy” Error
Once you mount a device in your system, any process with sufficient permission can access its filesystem. When the “target is busy” error occurs, it means that an active process is currently accessing a file or directory within the device.
Therefore, to prevent data loss, the Linux kernel will prevent you from unmounting the device when it’s being accessed.
But there are some instances where you need to remove the device. Let us discuss the various techniques you can use to do this.
Fix 1: Terminate the Running Process
We have established that the main cause of this error is an active process that is accessing a file within the device.
Therefore, to resolve this error, we can terminate the process, and the device will be free to be mounted.
Luckily, Linux has a command that allows you to show all the view the open files and the processes that are accessing that file.
You can learn more about about the lsof command here:
We can use the lsof command followed by the path to the disk. For example, if we are getting the error in device /dev/sda1, we can view the open files and the associated processes using the command:
$ sudo lsof /dev/sda1
The command should return the processes accessing the files are their IDs.
We can then take the PIDs and use them to kill the process.
$ sudo kill -9 [PID]
Once the process is terminated, you can unmount your device.
Keep in mind that there may be more than one process accessing a file. Hence, ensure to terminate all of them.
Fix 2: Force Unmount
Another solution for unmounting a busy device is to force it. This can be useful if the error is caused by an unreachable resource such as a network resource.
Keep in mind that force unmounting a device can lead to data loss.
To do this, use the -f option as:
$ umount -f /path/to/device
Fix 3: Lazy Unmount
The third and safer alternative to the force unmount is a lazy unmount. A lazy unmount allows the system to detach the specified mount point in a hierarchical manner. It works by removing any references to the filesystem as soon as it’s not busy.
And once no process is accessing the fs, the system runs the unmount command successfully and removes the device.
This is a safe option as you do not forcibly close any running processes. Instead, you allow the system to monitor once the operations are complete and then unmount the device.
To use a lazy unmount, use the -l flag in the umount command:
$ umount -l /path/to/dev
Conclusion
That’s it for this one. In this tutorial, we covered the cause of the “target is busy” error when unmounting devices in a Linux system. We also provided three solutions for unmounting the device appropriately.
As always, thanks for reading!!
About the author
John Otieno
My name is John and am a fellow geek like you. I am passionate about all things computers from Hardware, Operating systems to Programming. My dream is to share my knowledge with the world and help out fellow geeks. Follow my content by subscribing to LinuxHint mailing list
Fix “Umount Target is Busy” Error in Linux
It is not difficult to fix umount target is busy error. But what it means? While transferring data in any computer, if you unmount a USB flash driver/Data storage from your system while it is still busy on it, you face the error ”device is currently in use” and asks you to close programs first. While unmounting a device/portion on Linux, the same error occurs after running the umount command. Fix umount target is busy error in Linux is what you will learn in this article. It is not a complicated error and even helps to not lose your data but unless you solve it you cannot unmount your device.
After buying Linux VPS, you can access all the mounted filesystems. But if the accessed filesystems would not unmount, the ‘’device is busy’’ error does not let you continue. You are highly recommended to not unmount your device forcefully since it endangers your data or disrupts some running processes. So, join us with this guide to review all four methods you can use to pass this issue.
What is the ”Umount Target is Busy” error and why occur?
This error is simply saying that your device is still in use. In other words, a user or a process has an open file on that file system. Any process with sufficient permissions can access a device’s filesystem after you mount it in your system. An active process is actively accessing a file or directory on the device when the error “target is busy” appears. The Linux kernel will therefore prevent you from unmounting the device while it is being accessed in order to prevent data loss.
However, if you still need to unmount the target device, let’s learn how to fix umount target is busy error. Stay with us to review different methods to troubleshoot this error and in the end, you can decide which one is easier for you to use.
Tutorial Fix ”Umount Target is Busy” Error
Generally, the cause of umount target is busy error is an active process in your Linux system. When you have to unmount your drive, you need to find a solution to do this without data loss. According to different situations, one of the following methods would be helpful. In this part, you will learn all the best solutions to fix umount target is busy error.
Technique 1. Find and Kill Active Processes
Since the reason behind the ”umount target is busy” error is an active process, you must find and kill it. The lsof command views a list of open files to let you know what processes are associated with them. run the following command to find the process id (PID) first and then kill it.
sudo lsof /Path/to/targetThe above command lists all the processes using the mount point and does fix umount target is busy error. When the PID is displayed, it is time to terminate all running processes.
sudo kill -9 [PID]For example, if the output is saying that a process with PID 4255 is using the device, you need to run the command below to kill that process.
kill -9 4255You might find more than one process accessing a file, make sure that you have terminated all of them. In this way, all the processes that are attached to the device would be stopped, and you will be able to unmount the device.
Technique 2. Unmount Forcefully
While unmounting an NFS (Network File System), you might face the discussed error in this article. In this way, you can use the force unmount as a solution to detach your busy device. Since this method causes data loss, choose it when you have no valuable and sensitive data.
Run the command below to fix umount target is busy error and unmount the device forcefully:
sudo umount -f /Path/to/targetTechnique 3. Find and Kill Processes Accessing the File
The lsof command displays all open files on the mount point but the fuser command shows all the processes accessing the mount point. Since the Open (possibly deleted) socket is one of the reasons for the ”target is busy” error, the fuser command enables you to find the processes that are accessing sockets or files on filesystems. The -m option lists all the processes accessing the files. Also, you can add -v option for verbose. Run the command below to use this method and fix umount target is busy error.
fuser -mv /Path/to/targetOnce the processes which are using the file on the mounted filesystem are displayed, use the kill command to stop them all.
If you add -k option, processes will be killed at once. To achieve this, run:
fuser -kmv /Path/to/targetTechnique 4. Lazy Unmount
To fix umount target is busy error, a methodical way is the Lazy unmount. It unmounts the mount point from the Linux filesystem. To remove all the processes attached to the device (that are not in use) slowly, you can use this solution. Since the Lazy unmount removes all references to the detached file system, it will detach the file system when there is no more process accessing the unmounted file system. So, if the last suggested method is your choice, type:
sudo umount -l /Path/to/targetIn this way, all ideal processes will be automatically removed and the device will be unmounted. According to your used case, all the recent solutions can be chosen to fix umount target is busy error.
What if none of the methods works?
I guess you are using ClearCase. If yes, you are recommended to check /Vobs/Myvob since it might be the current working directory on a client host when unmounting. If the current directory sends target busy error, you can make sure that it is the current directory.
To solve this failure, you must turn ClearCase off since when unmounting, it should not be the working directory on a host client.
FAQ
Which method is recommended?
The first-mentioned solution, »using lsof command to find and kill active processes» , is recommended as the best way to unmount the target.
When to use the »force unmount» method?
Users who are working with Network File Systems usually prefer to use this method. So, it will not give ideal results on local file systems. Also, it is helpful when the error is caused by an unreachable resource such as a network resource.
Which technique is less harmful please?
The Lazy unmount is less harmful since it does not kill the process unexpectedly.
Conclusion
In this article, you learned how to Fix Umount Target is Busy Error in Linux. Now, you know the reason of occurring this error. Four different techniques such as detaching busy device by finding and killing the processes (lsof command), force unmount, using fuser command, and finally, lazy mount were explained. Keep in mind to run both lsof and fuser commands as root to have unlimited outputs. Using any of these methods helps you to troubleshoot this error. Based on your system and situation choose the best way to fix umount target is busy error.
Please do not hesitate to contact us if you encounter any problems. Our technical support team will try their best to solve your problems.
How to unmount a busy device [closed]
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year .
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
I’ve got some samba drives that are being accessed by multiple users daily. I already have code to recognize shared drives (from a SQL table) and mount them in a special directory where all users can access them. I want to know, if I remove a drive from my SQL table (effectively taking it offline) how, or even is, there a way to unmount a busy device? So far I’ve found that any form of umount does not work. Ignoring the possibility of destroying data — is it possible to unmount a device that is currently being read?
2,339 3 3 gold badges 15 15 silver badges 26 26 bronze badges
asked Oct 24, 2011 at 16:22
5,819 3 3 gold badges 21 21 silver badges 27 27 bronze badges
A more general answer addressing more causes for failing umount is found here oletange.blogspot.dk/2012/04/umount-device-is-busy-why.html
Jun 22, 2014 at 11:13
Hello, probably you cd to mounted dir, then you became root or login again then the other shell is trapped. Do exit on all shells.
May 5, 2020 at 23:24
Feb 13 at 20:28
16 Answers 16
YES!! There is a way to detach a busy device immediately — even if it is busy and cannot be unmounted forcefully. You may cleanup all later:
umount -l /PATH/OF/BUSY-DEVICE umount -f /PATH/OF/BUSY-NFS (NETWORK-FILE-SYSTEM) NOTE/CAUTION
- These commands can disrupt a running process, cause data loss OR corrupt open files. Programs accessing target DEVICE/NFS files may throw errors OR could not work properly after force unmount.
- Do not execute above umount commands when inside mounted path (Folder/Drive/Device) itself. First, you may use pwd command to validate your current directory path (which should not be the mounted path), then use cd command to get out of the mounted path — to unmount it later using above commands.
answered Nov 14, 2013 at 4:17
Amit Verma Amit Verma
8,730 8 8 gold badges 35 35 silver badges 40 40 bronze badges
Note: -l here is a lowercase L (for «lazy unmounting»). ( See this related answer. )
Feb 21, 2014 at 7:47
Worked. One nuance, if you are logged in through FTP client, you have to logout in order to successfully unmount folder.
Oct 22, 2014 at 16:47
Aug 12, 2017 at 6:14
Kinda scary. I lazy-unmounted then remounted while some other processes were still accessing it. So I guess I mounted it twice in the end to the same location? Not sure what that did.
Sep 8, 2017 at 0:42
Thanks, this answer help me with woeusb to create a bootable pendrive with windows
Oct 30, 2018 at 23:57
If possible, let us locate/identify the busy process, kill that process and then unmount the samba share/ drive to minimize damage:
- lsof | grep » (or whatever the mounted device is)
- pkill target_process (kills busy proc. by name | kill PID | killall target_process )
- umount /dev/sda1 (or whatever the mounted device is)
2,318 3 3 gold badges 15 15 silver badges 22 22 bronze badges
answered Oct 24, 2011 at 16:27
Frank Tudor Frank Tudor
4,266 2 2 gold badges 23 23 silver badges 43 43 bronze badges
That doesn’t return anything. I’m assuming its because its a network drive and I can’t see the processes of other computers accessing the drive. Same deal with the «fuser» commands.
Oct 24, 2011 at 16:40
oh hell. you need the samba commands. /usr/bin/smbclient service
Oct 24, 2011 at 17:17
The smb commands have actually been deprecated and replaced by «umount.cifs» . which also doesn’t work. It appears that I’m stuck with not being able to umount while its busy.
Oct 24, 2011 at 18:00
If you are using Asuswrt-Merlin, you need to install lsof : # opkg install lsof
Jul 24, 2019 at 17:18
you need to sudo lsof to get some results
Apr 25, 2020 at 10:14
Make sure that you aren’t still in the mounted device when you are trying to umount.
answered Apr 28, 2017 at 19:05
1,569 1 1 gold badge 8 8 silver badges 2 2 bronze badges
Exactly, simply having current folder (located on target device) opened in your terminal (through e.g. cd command) is enaugh to stop the unmnounting process 🙂
Jan 28, 2018 at 14:13
Yep, I had a shell running in a directory on the device. Closed the terminal window and voila
Dec 31, 2018 at 20:31
Also, make sure there are not any other mount points inside the one you are trying to umount .
Jul 19, 2019 at 8:19
@victe Thanks; I was mouting a folder using pfexec mount -F vboxfs carpetacompartida ~/Documents on Solaris 11; but Documents had subfolders and it was the issue.
Jan 29, 2020 at 20:44
I noticed that the regular FAT32 doesn’t care but ExFAT (like SSD drives) does care of PWD.
Jun 17, 2021 at 6:23
Avoid umount -l
At the time of writing, the top-voted answer recommends using umount -l .
- 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:
- All pending data has been written to disk
- All future write attempts will fail
- 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!
lsof +f -- /dev/ | 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:
- Temporarily duplicate the mountpoint with mount -o bind /media/hdd /mnt to another location
- Hide the original mount point and block the namespace:
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" - The original namespace hidden (no more files could be opened, the problem can’t get worse)
- 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
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
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.)
fuser -vmMki
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.
answered Sep 26, 2019 at 16:41
41.7k 36 36 gold badges 190 190 silver badges 245 245 bronze badges
If —lazy is so dangerous, why is there not so much as a warning in the umount man page? All it says is «Lazy unmount. Detach the filesystem from the file hierarchy now, and clean up all references to this filesystem as soon as it is not busy anymore.«
Jan 23, 2020 at 14:26
Remounting as read-only and then retrying the unmount helped. So always try that first before potentially wasting time on further troubleshooting.
May 5, 2021 at 22:12
@xdevs23: mount -o remount,ro + umount works if you have lots of sporadic writes but nothing actually hanging on the mount. Of couse, all processes trying to create writable files will get errors from read-only forward.
Jul 7, 2021 at 14:57
lsof +f — /dev/device helped me find the culprit process, and then I was able to unmount and remount
Jan 21, 2022 at 11:20
best answer, thanks. @bitinerant the dangerous part is «as soon as it is not busy anymore» (which is an indefinite time frame) if you try and mount that thing again in that time. already one commenter on the accepted answer seems to have done that. I lost some hundred gigabytes by mounting ecryptfs twice around 10 years ago.
Oct 6, 2022 at 19:20
Try the following, but before running it note that the -k flag will kill any running processes keeping the device busy.
The -i flag makes fuser ask before killing.
fuser -kim /address # kill any processes accessing file unmount /address 1,357 17 17 silver badges 22 22 bronze badges
answered Jun 30, 2014 at 7:44
user3751769 user3751769
619 5 5 silver badges 3 3 bronze badges
lsof | grep ‘/dev/
Feb 10, 2016 at 8:26
Running the fuser command immediately disconnected me from the VPS.
May 30, 2016 at 13:06
There’s no fuser in ubuntu 18.04
Oct 2, 2020 at 22:22
@giorgio79 If the current working directory of your shell is inside the device that you’re trying to umount , of course, killing the shell is required to unmount the device. It’s always best to do cd / before trying to umount anything.
Jul 7, 2021 at 14:59
Before unmounted the filesysem. we need to check is any process holding or using the filesystem. That’s why it show device is busy or filesystem is in use. run below command to find out the processes using by a filesystem:
fuser -cu /local/mnt/
It will show how many processes holding/using the filesystem.
local/mnt: 1725e(root) 5645c(shasankarora)
ps -ef | grep 1725 ps -ef | grep
Kill all the processes and then you will able to unmount the partition/busy device.
answered Dec 8, 2021 at 17:52
shashank arora shashank arora
1,196 11 11 silver badges 14 14 bronze badges
Check for exported NFS file systems with exportfs -v. If found, remove with exportfs -d share:/directory. These don’t show up in the fuser/lsof listing, and can prevent umount from succeeding.
answered Apr 20, 2014 at 15:02
131 1 1 silver badge 1 1 bronze badge
Thanks for this advice. I had to use exportfs -ua to remove the lock.
Apr 14, 2015 at 8:36
Just in case someone has the same pb. :
I couldn’t unmount the mount point (here /mnt ) of a chroot jail.
Here are the commands I typed to investigate :
$ umount /mnt umount: /mnt: target is busy. $ df -h | grep /mnt /dev/mapper/VGTout-rootFS 4.8G 976M 3.6G 22% /mnt $ fuser -vm /mnt/ USER PID ACCESS COMMAND /mnt: root kernel mount /mnt $ lsof +f -- /dev/mapper/VGTout-rootFS $ As you can notice, even lsof returns nothing.
Then I had the idea to type this :
$ df -ah | grep /mnt /dev/mapper/VGTout-rootFS 4.8G 976M 3.6G 22% /mnt dev 2.9G 0 2.9G 0% /mnt/dev $ umount /mnt/dev $ umount /mnt $ df -ah | grep /mnt $ Here it was a /mnt/dev bind to /dev that I had created to be able to repair my system inside from the chroot jail.
After umounting it, my pb. is now solved.
answered Oct 1, 2020 at 22:19
4,101 29 29 silver badges 40 40 bronze badges
I also had a mount in the mount. Of course lsof, fuser, exportfs and others show nothing.
May 17, 2021 at 10:07
Linux 2.1.116 added the umount2() system call, which, like umount(), unmounts a target, but allows additional flags controlling the behaviour of the operation:
MNT_FORCE (since Linux 2.1.116) Force unmount even if busy. (Only for NFS mounts.)
MNT_DETACH (since Linux 2.4.11) Perform a lazy unmount: make the mount point unavailable for new accesses, and actually perform the unmount when the mount point ceases to be busy.
MNT_EXPIRE (since Linux 2.6.8) Mark the mount point as expired. If a mount point is not currently in use, then an initial call to umount2() with this flag fails with the error EAGAIN, but marks the mount point as expired. The mount point remains expired as long as it isn’t accessed by any process. A second umount2() call specifying MNT_EXPIRE unmounts an expired mount point. This flag cannot be specified with either MNT_FORCE or MNT_DETACH.
4,864 1 1 gold badge 30 30 silver badges 42 42 bronze badges
answered Oct 24, 2011 at 16:26
52k 16 16 gold badges 134 134 silver badges 170 170 bronze badges
Unforunately these aren’t NFS mounts, but CIFS. I will try the MNT_DETACH though. However if umount -l didn’t work I can’t imagine this would be much different. Thanks though!
Oct 24, 2011 at 16:35
I recently had a similar need to unmount in order to change it’s label with gparted.
/dev/sda1 was being mounted via /etc/fstab as /media/myusername. When attempts to unmount failed, I researched the error. I had forgotten to unmount a dual partitioned thumb drive with a mountpoint on /dev/hda1 first.
I gave ‘lsof’ a go as recommended.
$ sudo lsof | grep /dev/sda1 The output of which was:
lsof: WARNING: can’t stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
lsof: WARNING: can’t stat() fuse file system /run/user/1000/doc
Output information may be incomplete.
Since lsof burped up two fuse warnings, I poked around in /run/user/1000/*, and took a guess that it could be open files or mount points (or both) interfering with things.
Since the mount points live in /media/, I tried again with:
$ sudo lsof | grep /media The same two warnings, but this time it returned additional info:
bash 4350 myusername cwd DIR 8,21 4096 1048577 /media
sudo 36302 root cwd DIR 8,21 4096 1048577 /media
grep 36303 myusername cwd DIR 8,21 4096 1048577 /media
lsof 36304 root cwd DIR 8,21 4096 1048577 /media
lsof 36305 root cwd DIR 8,21 4096 1048577 /media
Still scratching my head, it was at this point I remembered the thumb drive sticking out of the USB port. Maybe the scratching helped.
So I unmounted the thumb drive partitions (unmounting one automatically unmounted the other) and safefly unplugged the thumb drive. After doing so, I was able to unmount /dev/sda1 (having nothing mounted on it anymore), relabel it with gparted, remount both the drive and thumb drive with no issues whatsoever.
Bacon saved.