Hello,
I was minding my own business on my computer (watching some video and twiking some pdf) when the electricity shut down in the whole house. The system is running again and the faulty device is shut off. I turned my computer back on and now, I have an error message when I’m trying to access my HDD 
I had issues before due to the fact that it is an NFTS partition (Previous thread). Should I explore this path again or is it possible the electric system crash caused another issue ?
This may not have anything to do with your particular issue, but when our power has gone out, one of my PCs (an older Dell Optiplex) would fail to boot up again too.
I found the solution was to power up in BIOS mode (a hardware thing, like holding F12, or some such depending on make/model) and then confirm that all of my selections are accurate - because the power failure who fritz the storage and lose some of them.
I find that checking the start up default drive, UEFI choice, etc., must be confirmed to function properly again.
Hope this helps … or else someone with more insight can guide you. 
I’m not certain this help because the computer is booting properly (i’m using it right now and it’s a tower, not a laptop) and I can access the data on the SSD (where the OS is running).
Your computer didn’t boot at all, if I understand correctly ?
Correct - the flash RAM lost track of the BIOS/UEFI selections otherwise in storage. Sounds like you will likely need some better ideas. Best wishes.
That is file system corruption. As it’s NTFS, you can either boot into Windows and fix it or if that’s not an option, try to fix the NTFS partition running chkdsk off Hiren’s BootCD
If the drive is a mechanical hard drive (no ssd or nvme) the power loss probably caused a power peak , resulting in the HDD to get “fried”.
So the same thing as last time ? Ok, I’ll go for that (and I have 2 SSD, one for Linux and one for Windows so both are possible)
Ok, let’s hope that’s not it and that the power unit did it’s job …
So I booted on Win and checked the fast startup (still incheck) and ran an chkdsk :
C:\Windows\system32>chkdsk /f
The type of the file system is NTFS.
Cannot lock current drive.
Chkdsk cannot run because the volume is in use by another process.
I did it twice, shuting down the computer in between … As the chkdsk did the trick last time, I was hoping it would solve everything but no, not today … Should I install ntfs-3g ? But it’s been installed previously so it doesn’t seem to make any sense to newbie me …
(I did a chkdsk with no disk specified and didn’t get anything special that I could see … )
Don’t worry, this doesn’t sound like a fried drive, and it’s very unlikely that installing ntfs-3g will help here.
What you’re seeing is actually normal Windows behavior:
chkdsk /f cannot run on the system drive while Windows is running, because the filesystem is in use. That’s why you get:
Cannot lock current drive
What you need to do instead is schedule the check for the next boot.
In Windows, open an Administrator command prompt and run:
chkdsk C: /f
When asked whether you want to run it on the next restart, answer Y, then reboot and let Windows finish the check before it boots fully.
Important notes:
ntfs-3g on Linux cannot fix NTFS metadata corruption that Windows itself has locked.Once Windows has completed chkdsk successfully, Linux should be able to mount the NTFS partition again without errors.
If Windows also can’t repair it at boot, then tools like Hiren’s BootCD or a Windows recovery environment are the next step — but you’re not there yet.
Take it one step at a time 
Thanks you for all those explainations. Just a quick question before switching to Windows :
I use grub for the dual boot and if left untouched, Linux will startup. Should I first go into the BIOS to change this setting ? (I guess that’s where it is defined but I’m not certain)
No worries — no BIOS change needed
Short answer: leave the BIOS alone.
What you should do instead:
chkdsk C: /f and allow it to schedule the checkGRUB only decides which OS starts, it does not affect the filesystem repair at all.
As long as you boot Windows via GRUB, everything works exactly the same as if Windows were the default.
Only go into the BIOS/UEFI if:
In your case, just pick Windows from GRUB and you’re good 
So the chkdsk did not solve the issue
You’re talking about Hiren’s BootCD or a Windows recovery environment … I guess I should prepare a USB drive for this ? Does it mean going through a clean install for Windows ? (I had to do it once in a while before but my system was Windows only and I had multiple disks to store data and software).
No worries — this does NOT mean a clean Windows reinstall
You’re still in repair mode, not “nuke & pave”.
Good news first:
Seeing “Windows Recovery Environment” means Windows still recognizes the installation. If it were truly broken, you wouldn’t even get that far.
Since chkdsk didn’t fix it from inside Windows, the next step is offline repair, not reinstall.
(which would break grub)
Yes, prepare a USB stickYou have two good options:
From there run:
chkdsk C: /f /r
This runs offline, which is much more effective than in-system checks.
chkdsk C: /f /r
Same goal, different tool.
A clean install only happens if you explicitly choose “Install now”.
When NTFS metadata is damaged or still flagged “dirty”:
Once chkdsk finishes successfully:
The NTFS partition should then mount normally again.
If offline chkdsk /r also fails, then we talk about:
Yes, make a USB stick.
No, this does NOT mean reinstalling Windows.
You’re doing an offline NTFS repair — the correct next step.
Thanks again for all this.
Again a technical question : is the version of Windows running important or not ? I have a Win10 Enterprise edition. Does it matter or the WRE is the same no matter what ?
Why not try the linux command
sudo ntfsfix dev/xxxx
Where xxxx is your device.
Edit: I saw your other topic where this happened before. I see chkdsk -f fixed it before.
Short answer: no, it doesn’t matter
Your Windows 10 Enterprise is absolutely fine for this.
Longer (but still simple) explanation:
chkdsk, diskpart, and the repair tools behave identicallySo for what you’re doing right now (offline NTFS repair):
The only things that do vary by edition (BitLocker policies, domain features, etc.) are irrelevant here.
What does matter:
chkdsk /f /r finish completelyIn other words:
You’re fixing a filesystem, not Windows itself — and NTFS doesn’t care about editions 
ntfsfix is not a replacement for chkdsk.
What ntfsfix actually does:
chkdsk on next bootWhat it does not do:
Because NTFS is proprietary and Linux tools are reverse-engineered, ntfsfix can indeed make things worse if the filesystem is already damaged — especially when Windows has marked it inconsistent.
Best practice:
ntfsfix only as a last resort to make a volume mountablechkdsk /f /r from WinRE or recovery USB)So in this case, sticking with Windows recovery is the correct and safest path.
Yes that could be. I have seen ntfsfix used sometimes and it worked. Yes things could also get worse. But on the other hand that could also happen anyway using Windows tools!
That’s a fair point, and you’re right on both sides.
ntfsfix can work, and many people (myself included) have successfully used it — but it’s important to understand what it’s for.
ntfsfix is useful when:
I’ve had a similar case with a large NTFS USB drive throwing constant errors.
ntfsfix allowed me to access the data and copy everything to an ext4 disk.
After that, I wiped the drive, re-initialized it, ran full SMART tests — hardware was fine.
The real problem was the NTFS filesystem, not the disk.
That said:
ntfsfix is not a full repair toolchkdsk /f /rSo the practical rule of thumb is:
ntfsfix for data recoveryAnd if you have the choice going forward:
ext4 is simply a much more robust and stress-free filesystem.
NTFS works, but it carries a lot of legacy behavior — when things go wrong, they tend to go very wrong.