This content originally appeared on DEV Community and was authored by Abhijit Kumar
Ever come across a situation where you wanted to resize an external ssd, and ended it up messing the ssd drive completely.
External SSD's especially those on NTFS are extremely sensitive to structural changes and if certain partitions of the disk are moved or resized, they might just give an error in the auto-mount process. At the same time, it will be reasonable to say here that your data remains safe provided that you have not completely erased your ssd or formatted it.
Recently, I was resizing an external SSD that I occasionally use to store data - some books, movies, etc. I wanted to free a portion of the ssd space so as to later install Ubuntu on it. That's right, you can install Ubuntu in an external disk already containing some data. After following the usual process of live booting into gparted(a tool used to move/resize drives) and resizing my ssd into the required structure, I rebooted into my current OS ArchOS. I double clicked the ssd and it showed an error :-
Failed to mount "Seagate Expansion Drive"
I was confused, the disk was clearly showing in the connected devices yet was giving an error on opening. Moreover, such things usually do not happen in Linux OS's. I tried not to panic and instead find the solution; after all around 600 gigs of my data was at stake. I entered the following commands in the terminal :-
lsblk -f # to list all the connected drives
# my device was listed as /sdb1
sudo mkdir -p /mnt/external
sudo mount /dev/sdb1 /mnt/external # to mount all the data
This allowed me some headspace, I could see all the data in this mounted folder; at least my data was safe. This is the first thing you should do when your data gets lost, try to mount it to a folder and see if you can recover your data. Then, I tried to fix my ssd of any errors :-
sudo ntfsfix /dev/sdb1 # my drive is ntfs
sudo fsck.exfat /dev/sdb1 # for exfat
sudo fsck.ext4 /dev/sdb1 # for ext4
I unplugged the disk and reconnected it. Still the same behaviour. In such cases it is advisable to check for the dirty bit(more about it later) :-
sudo ntfsfix --clear-dirty /dev/sdb1 # clears the dirty bit
and voila, it worked. I was happy again, to see my external ssd mount again in the usual fashion and guess what all the data was intact; ntfs does a good job at that!
So, turns out that if the external ssd is not properly unmounted and safely removed, it might get marked as "dirty". When I later plugged it into my normal Linux system, it refused to auto-mount to prevent data corruption.
If you would like to connect with me or share a thought, you can do so at :-
abhijit105 @ LinkedIn
Abhijit105 @ GitHub
Image credits: Mariakray @ Pixabay
This content originally appeared on DEV Community and was authored by Abhijit Kumar
Abhijit Kumar | Sciencx (2025-08-06T14:59:57+00:00) Dirty bit in NTFS. Retrieved from https://www.scien.cx/2025/08/06/dirty-bit-in-ntfs/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.