You appear to have created the entry in fstab using gnome-disks.
Unless you have very specific requirements - you should not use fstab.
Using the auto parameter will make the system guess - if you absolutely must have the device in fstab - use ntfs3 instead of auto.
I am speculating - I have come to a point where I really have to find a Windows system and create a disk formatted with ntfs to be sure how the kernel handles this.
gvfs/kio should handle all the details - you should only need to access the device from the file manager for it to mount.
Luckily I have this Surface Pro X arm tablet with Windows.
Done and done.
Without further interaction - I can mount and read write the ntfs file system and gvfs mounts using ntfs3.
$ mount
[...]
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sdj1 on /run/media/fh/New Volume type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,uhelper=udisks2)
Whether it is kio or gvfs - no further configuration or setup needs to be done.
Unless of course you have games shared between Windows and Manjaro Linux - but that is not a recommendable setup - for various reasons.
I am really lazy and have mp3 and Freepascal develop files on this ntfs device, so i auto mount it with gnome-disks via fstab … it was working for years now without issues. So i think ntfs3 is behind fuseblk, even if i don’t see ntfs3 in lsmod … its working ok!
The ArchLinux Wiki on [ntfs] tells us there is no userspace tools for ntfs3 so one has to sort to a custom package if one needs userspace tools.
The wiki also states that if you use mount - your need to specify ntfs3 using the -t option.
Since that is what fstab uses - you should move from auto to ntfs3 for your ntfs formatted device - to be sure you know which driver is used - I am assuming you still have the ntfs-3g package installed.
Perhaps the widely used auto with fstab - possibly stemming from creating the mount using gnome-disks and mounting to a non-existing mountpoint in /run/ tree is cause the frequently seen issues with members having issues mounting ntfs devices.
One can only guess …
The wiki also passed on the knowledge that you can default your block devices to use ntfs3 by means of an udev rule - see NTFS - ArchWiki
Changed back to parameter “auto” instead of “ntfs3” in my fstab because even if mount shows “rw” i could not create|delete a file on the ntfs device … “never change a running system” especially with so poor knowledge as i have !!
Here is how Thunar on XFCE mounts vie udisk i think if one clicks on NTFS volume from the file manager
/dev/nvme0n1p3 on /run/media/teo/Windows-SSD type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,uhelper=udisks2)
And i do indeed can write on the ntfs. I do not know if it is a good idea though, i read somewhere ntfs3 could cause corruption, but i am not sure if that applies for older versions or is still valid…maybe someone can advise?
That possibly stems from someone not knowing that ntfs3 is designed to prevent an NTFS volume from mounting (if the dirty bit is present).
It’s not too difficult to imagine some dumb- ranting “ntfs3 has corrupted my disk - wah wah wah” simply because they didn’t know any better.
The ntfs3type should be specified when you’re certain that a volume is being mouted by ntfs3; and not by ntfs-3g, or something else. This applies whether using fstab, systemd units or any other method to mount a volume.
The main concern, I think, might be syntax, as not all tools that should use the ntfs3 type are necessarily using it; which suggests there’s quite some catchup to be done in some cases, considering we’ve had ntfs3 since it was introduced in kernel 5.15.x series.
I believe ntfs-3g is only an optional dependency for those (I have not checked), and they should otherwise use ntfs3 or whatever the default driver happens to be.
and a grumpy old man 
ranting “ntfs3 has corrupted my disk - wah wah wah” simply because they didn’t know any better.