Ah, that it reads fuseblk instead of NTFS it the same thing that dietpi-drive_manager did ~2 versions ago @Joulinar
. NTFS in fstab is the correct "ordered" filesystem type, but internally fuse is used by the ntfs-3g driver to achieve this and have UNIX permissions (and symlink?) support.
Strange is that we don't use findmnt here, like drive manager did, but
. Can you verify that it reports back "fuseblk" for the NTFS drive, like
The solution was to use
blkid -s TYPE -o value
, which reports NTFS back correctly. But sadly this cannot be used here directly, since we have a given directory, but not a drive. So we'd first need to find the drive/partition which hosts the target directory and then check via blkid its filesystem type.
So but now for this case, NTFS is still not supported currently: https://github.com/MichaIng/DietPi/blob ... up#L77-L95
The problem is that NTFS natively does neither support UNIX permissions, nor symlink. Both is strictly required to backup a system, as the system itself makes heavy use of both. Restoring a system with UNIX permissions and/or symlinks lost would be simply unbootable. These features for NTFS are "faked" by the ntfs-3g driver. But if anything with it is broken, e.g. related to the reason you want to restore, or if you want to restore it to a fresh system, it can fail. I'm not even sure if ntfs-3g allows to create symlink, or only reads existing Windows links as symlinks.
I'm not sure what POSIX defines for filesystems, but NTFS does definitely NOT support UNIX permissions and symlinks. Do
apt purge ntfs-3g
and try it out yourself
. Windows, which NTFS is designed for, has a different concept for both, permissions and links.
The filter settings state that symlinks "are handled as such", hence copied as symlinks also to the backup target, instead of being processed recursively, meaning to copy the file or directory content the symlink is pointing to, instead of the symlink as such. As stated above, this is strictly required for a functional system backup.