user1@FOB-Mate-20:/etc$ sudo ntfsfix /dev/sdd2
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdd2 was processed successfully.
Rebooted, still unable to mount. Is there correction other than what I'm doing?
So I connected the drive to a windows machine and the files were accessible. Everything was there. When I re-connected it to my Linux box, now, no error showed up but still can't connect to it.
As far as GParted goes, GParted does not even recognize sdd1 or sdd2.
Ran:
user1@FOB-Mate-20:~$ sudo fsck /dev/sdd
[sudo] password for user1:
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdd
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
Found a gpt partition table in /dev/sdd
AND
user1@FOB-Mate-20:~$ sudo ntfsfix /dev/sdd2
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdd2 was processed successfully.
From Hatch.JS link above, it suggested df -T, but it did not find sdd1 or sdd2
For external drive, I recommend to use ExFat partition instead of NTFS. Because better support for working on both Linux/Windows. Also, if windows shutdown with fast startup, then it lock NTFS partition which can't be read on Linux.
I would suggest using one of the command line partition editors (parted, cfdisk, fixparts) that you are most comfortable with to
list the partition details
confirm that you have all that information saved for reference, then
re-save that disk's partition tables.
That should only impact the UUID, if even that.
In my estimation, it is possible that there is some kind of age-related issue (specifically ... too many disk reads, leading to block de-magnetization). Re-writing that partition table's impression on disk with no change should leave the disk data untouched, but the partition table accessible with greater ease.
It's just a thought, even if it is a bit extreme as a solution.
The only other thought I have is that there may be a need to specify a "quirk" as part of your GRUB boot configuration, that specifically addresses some I/O issues related to that particular model of drive. That is what I had to do for in order to properly used my external 4TB MyBook USB drive. References on that are detailed here.
I believe this command was incorrect. sdd is the entire disk (itself isn't a valid partition). sdd1, sdd2 are the partitions, which might explain the superblock error.
How is the disk being mounted (e.g. click in the Caja sidebar)? Do you get the same error if you manually mount? Maybe also try the ro option for read-only:
sudo mount -o ro /dev/sdd2 /mnt
The error could happen if you don't have the NTFS driver installed, or it's been blacklisted. I think one of the packages providing NTFS support is ntfs-3g.
Generally, for NTFS filesystem errors, I think running chkdsk /F X: on Windows (its native environment) is better to fix them - if the issue is due to some inconsistency.
I formatted a 250 gig Simple Drive to ext. 4. It would not be recognized on Windows and gave me permission problems on Linux. It was locked on any other computer and with any other user on that same computer. When I copied as the original user to a USB drive, every thing I copied was also locked.
I had that happen on USB drives too. I now only use fat32/exfat.
After connecting it to a Windows machine and backing all the files up, I reconnected to my Linux box and ... for grins, in Disks again, ran Check Filesystem and Repair Filesystem ....and it connected. Not sure if it was the act of connecting to the Windows machine and backing everything up or running the Repair Filesystem in Disks is what did the trick. Regardless, it's working.
Thank you all for your input, very helpful.
Philippe mentioned reformatting the drive from NTFS to exFat, which makes sense. This link has a good comparison chart of FAT, exFat and NTFS.
From the HatchJS link above, it has this:
For example, to change the file system type of a device to ext4, you would use the following command:
$ mkfs.ext4 /dev/sda1
My question is can exFat be substituted for ext4?....changing the path of course.