Dietpi Backup: Filesystem type not supported

General Discussion
1

I have a usb drive formatted as NTFS and was trying to use dietpi-backup to store there, however I get this message:

┌─────────────────────────────────────┤ DietPi-Backup ├─────────────────────────────────────┐
│                                                                                           │
│ Filesystem type not supported:                                                            │
│                                                                                           │
│ /mnt/usb/dietpi-backup has a filesystem type of fuseblk, which is not supported.          │
│                                                                                           │
│ The filesystem type must be ext2/3/4, F2FS, Btrfs, XFS or ZFS for symlink and POSIX       │
│ permissions compatibilities.                                                              │
│                                                                                           │
│                                          <Ok>                                             │
│                                                                                           │
└───────────────────────────────────────────────────────────────────────────────────────────┘

This is strange,

  1. I believe the ‘filter’ settings state that symlinks will not be copied anyhow, and
  2. from my understanding NTFS is POSIX compliant (https://social.technet.microsoft.com/wiki/contents/articles/10224.posix-and-unix-support-in-windows.aspx)

The usb drive is auto-mounted as ntfs with dietpi-drive_manager, fstab shows:
UUID=XXXXXXXXXXXXXXXX /mnt/usb ntfs noatime,lazytime,rw,permissions,big_writes,nofail,noauto,x-systemd.automount


Is there something I’m missing?

2

something for the developer to be answered

ping MichaIng

3

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 df -T. Can you verify that it reports back “fuseblk” for the NTFS drive, like findmnt does?

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/81ba362/dietpi/dietpi-backup#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 :wink:. 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.

4 
# df -T
Filesystem                Type       1K-blocks        Used  Available Use% Mounted on
/dev/root                 ext4       378355016    57385036  305575224  16% /
devtmpfs                  devtmpfs     3873624           0    3873624   0% /dev
...
/dev/mmcblk0p1            vfat          258095       32045     226051  13% /boot
/dev/sda2                 fuseblk    468842492   208899016  259943476  45% /mnt/usb
//192.168.XXX.XXX/NS1   cifs     39045228480 33868223128 5177005352  87% /mnt/NShare1
//192.168.XXX.XXX/NNTFS2 cifs      9766303740  9679852508   86451232 100% /mnt/NShare2
/dev/sdb1                 fuseblk   2930262012  2697043872  233218140  93% /mnt/usbstore




│ └─/mnt/usb                    /dev/sda2            fuseblk     rw,noatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096

the NTFS Network drive is recognised the same as the other network drive (btrfs), ie as cifs. Is this normal? (mounted via dietpi-drive_manager)

So only *nix formatted drives can be used in that backup option, since its like a system image backup/restore (using files with system settings), not just a file backup?

Is there any simple filebackup option that can use NTFS drives thats part of the dietpi-software suite? I’d like to also be able to use the drive on any Windoz pc, if anything goes wrong.

5

dietpi-backup is doing file system backups but it is important to keep file permissions and sym links. Our backup tool is basically using rsync to backup data.

6

Yes dietpi-backup does a system backup, to restore an earlier system state when something got lost or broken.

If you want to backup only certain files, check out dietpi-sync. It works pretty similar (rsync based), allows you to choose source and target dir and you can also have it running on a daily bases.

7

I’m surprised there’s no bridging translation between *nix FS and NTFS for file/folder permissions, ownership, simlinks, etc. built in, since NTFS does allows for them in a similar way (except the special filetypes cbps, and special permissions st).

I checked out dietpi-sync and UrBackup. Urbackup seemd a little more suited for me due internet transfering and so I can remove any via’s for syncing over the internet and go direct…even though the dietpi implementation of UrBackup requires changing the group to ‘dietpi’ and tweaking with some of the permissions, etc. and the client installs can be a little tricky to install and configure.

8

UNIX permissions and symlinks cannot be fully expressed on NTFS, without loosing information, and the other way round. The ntfs-3g driver is able to emulate it partly, but e.g. in case of symlinks: Windows has two types of links, shortcuts and directory links (not sure how they are called correctly), and those require a drive letter, like C:, a concept which does not exist at all on Linux/UNIX, so there is no way to create such from a Linux system on an NTFS drive, as it does not even know which drive letter it will have on Windows. UNIX symlinks can have relative paths, which is not possible on Windows, so trying to create such would be garbage on Windows. And symlinks can link to files and directories, and even when changing the target from a file to a directory, or to another symlink, the symlink stays valid. On Windows, a directory link is completely lost as fast as the directory is removed, and a shortcut is a completely different thing, filesystem wise. So while the Linux driver can interpret shortcuts and directory links as absolute path symlinks, by removing the drive letter and prefixing it with the mount point (or so, not sure how it works), it cannot create them, as it would create the false type in 50% of cases and would behave very different on Windows or be complete garbage.

The UrBackup server should have sufficient permissions to write to its default data directory (/var/lib/urbackup, I think). We do not change anything about that. If this was not true, can you give some details how it failed, like error messages or so?