I understood that the solution was to run the Windows Chkdsk command and I did it.
Next time I could mount the external drive in Manjaro and run my data backup script, it worked as desired, i.e. my bash srcipt - which essentially runs a duplicity command - stored the duplicity backup files on my external hard disk drive.
However, next time when I tried to mount the drive in Manjaro in order to run my data backup script, the ntfs error occurred again:
Error mounting /dev/sda1 at /run/media/afesi/DRIVE-N-GO: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.
Note that I had not used the drive in the meantime, neither in Windows nor in Manjaro!
Did my bash script possibly cause the error?
Again I executed the Windows Chkdsk command. After that I was again able to mount my external disk and run my backup script.
My current impression is that every execution of my backup bash script leaves the NTFS partition on my hard disk drive in a dirty state, i.e. after every backup I need to repair the drive with Windows chkdsk, before I can mount the drive in Manjaro and run my script again.
How can I find out what happens exactly in order to find a persistent solution of that problem?
I don’t know how to find out what happens,
but a persistent solution would be to use a Linux native file system on that drive or on a partition on it,
instead of NTFS.
There are two versions of drivers for NTFS.
One simply ignores any errors,
the other one makes you fix them before you can proceed.
How to find out what the error was and why it occurred? No idea.
This article will hopefully give you some insight into the woes of using an NTFS filesystem under Linux. All that’s required is to read and understand:
The dirty bit is an indicator of damage; for NTFS volumes, chkdsk is the safest method to check for and repair any damage and remove the dirty bit.
I presume this much is understood. Fine.
The question of why this seems to happen repeatedly with that one removable USB disk could potentially be answered by a number of scenarios.
Did my bash script possibly cause the error?
Possibly. I suppose only you could know. I don’t know the specifics of the backup you’re performing with that script; however, I’d question the wisdom of backing up files from a Linux filesystem to an NTFS formatted destination. Perhaps this is a consideration. A possible workaround might be to format this disk as EXT4.
Are you multibooting with Manjaro and Windows?
If Windows Fast Startup (a hibernation variant) is enabled, this can cause a dirty bit to be triggered on unsuspecting volumes, whether damage exists or not.
When you performed chkdsk on the drive, perhaps it needed more: chkdsk /f x: will usually filesystem errors but if the disk has deeper issues, you might need to try more advanced chkdsk options; such as /r (for example), which also checks for bad sectors and (if found) marks them as bad so that data is no longer written to them.
It’s also possible that the removable drive doesn’t have a stable connection: the cable or connector(s), or the disk itself, might need replacing. I experienced something similar once myself; a connector failed to connect properly at even the slightest touch, unless it was seated at a specific position.
If you manually disconnect the disk before it’s fully unmounted; or if you sometimes reboot while leaving the disk connected. Either of these conditions might trigger a dirty bit, in which case it would be habit that needs to change.
NTFS is at best a reverse engineered proprietary filesystem.
Using NTFS with Linux is subject to change without notice - that is how it is.
If mounting a ntfs partition fails with the error:
Error mounting /dev/sdXY at […]: wrong fs type, bad option, bad superblock on /dev/sdXY, missing codepage or helper program, or other error
and in the kernel log with journalctl/dmesg ran as root:
ntfs: (device sdXY): parse_options(): Unrecognized mount option windows_names.
Then the problem is that udisks is trying to use the kernel ntfs driver, which does not understand this (default) mount option. For this to work the optional dependency NTFS-3G must be installed.
– udisks - ArchWiki