dd?

Flatpak – It’s not without it’s own issues, of course, but it does the job. I’m not fan of how snaps are designed, and I don’t think canonical is trustworthy enough to run a packaging format. Appimages are really just not good for widespread adoption. They do what they are designed to do well, but I don’t think it’s wide to use them as a main package format.

I’ve heard that ReFS is supposedly replacing NTFS, on Windows.

For your reference, please see the updated post. I ran a S.M.A.R.T test, and the drive is indeed borked.

Thank you very much for all of the extra information!

I ran a S.M.A.R.T short test, and, yeah, the hard drive is quickly dying:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   001   001   051    Pre-fail  Always   FAILING_NOW 1473

That disk certainly isn’t healthy.

For my own future knowledge, what, exactly, in the logs, led you to that conclusion?

image the whole thing with ddrescue

Since you mention “image”, I’m assuming that I would need a drive at least equal to the size of the source drive to store the image? The issue is that the source drive is 2TB in size, so I would need to source another 2TB drive (at least) to store the image.

Unfortunately, I am unable to downgrade to LTS. I need the latest kernel version for a my WiFi card (I’ve had a ton of annoying driver issues with this specific card that seem to now be fixed in the latest few kernel updates).

Nothing logged.

I have the exact same issue. I’ve never been able to see any errors in the logs. Essentially just says “going to sleep” then that’s it.

Using Nvidia with closed source drivers by chance?

No, I have an AMD GPU.

some hardware specs might help others with assisting you.

Noted! I’ll update the post.

Ah, dang, yeah that would do it. Thank you!

It appears I have misread the stack exchange posts I was looking at. I thought I read that they said that chown, by default, traverses the symbolic link, but, in actuality, what they were saying was that it, by default, changes the ownership of the target file of the symbolic link.