I usually just take the risk and just run with it. 
Edit: Sometimes reverse engineered tools running on a different platform actually do work better.
I don’t really care much for ntfs fs to begin with. 
Soooo i just finished creating the boot key ^^ to be continued … tomorrow. Sorry for the cliffhanger 
New day, new m… New updates =D I did the daily updates and tried to access the HDD because, you know, just in case … And my luck has turned (or whatever it is) and I can access my drive again. Maybe it just needed a good night sleep ?
Thank you for your support and, @GHUL for all those explanations, it might come in handy later (way, way later, I hope).
What you are seeing is actually a very typical post–power-loss scenario, especially with NTFS on Linux.
What likely happened
A sudden power outage can cause multiple, independent effects at the same time:
-
NTFS was not cleanly unmounted
NTFS is not a native Linux filesystem.
If the journal or metadata was mid-write when power was lost, Linux will correctly refuse to mount it RW. -
UEFI / BIOS settings may have partially reset
This happens more often than people think:- boot mode (UEFI ↔ legacy)
- storage controller mode (AHCI / RAID)
- boot order
Simply entering firmware setup and re-confirming settings can already fix part of the problem (as suggested above).
-
Filesystem protection, not corruption
In many cases this is not data loss, but Linux protecting you from making things worse.
Why NTFS makes this more painful
NTFS expects Windows-style recovery semantics.
Linux can read and write NTFS very well, but it cannot fully replay NTFS journals the way Windows does.
So after a hard power cut:
- Windows says: “I’ll fix that later”
- Linux says: “Stop. Prove it’s safe first.”
Both behaviors are correct — just different philosophies.
Recommended recovery path (safe order)
Check firmware first
-
Enter BIOS/UEFI
-
Verify:
- correct boot mode
- correct drive detected
- correct boot order
Check NTFS from Windows (preferred)
If possible:
chkdsk /f X:
(where X: is the affected drive)
This is the cleanest way to clear the NTFS dirty flag.
Linux-only workaround (if Windows is not available)
Mount read-only first, verify data, then:
ntfsfix /dev/sdXn
Note: ntfsfix is not a full repair tool — it just makes the filesystem mountable again.
Important lesson (no blame, just experience)
If a disk is actively used under Linux, especially after crashes or power loss:
Use a native Linux filesystem (ext4, btrfs, xfs)
Keep NTFS for exchange / compatibility, not as a primary working filesystem
This avoids exactly this class of problems.
TL;DR
- Power outage didn’t “mysteriously break Linux”
- NTFS + hard power loss = expected safety lock
- BIOS checks + filesystem verification usually resolve it
- Linux didn’t fail — it refused to guess
Your system didn’t heal itself magically —
it simply refused to lie to you until things were consistent again 
Thank you again for this clarification. There’s still so much for me to learn and understand on Linux so answers like yours help me get there little by little.
I have one last question about the filesystem though : I have one HDD used for keeping all my data. It’s a 8 To that I can access from Linux and Windows (so I could check yesterday that it seemed undamaged as I could access it from Windows). If I decide to switch from NTFS to, let’s say, ext4, apart from the hassle of copy/paste everything one way and then the other, would it be also accessible (read/write) from Windows ?
Beside the space issue (I have some room for HDD but not that much), I also need to access my drive from both sides, for example so that I can print (which I can’t do right now from Linux but that’s another day’s side quest). Or is there another filesystem that can be used from both sides ?
(I’ll mark the topic as solved and your last answer as THE solution given all the explanation summarized there but if that’s not the way, please feel free to tell me)