NTFS-3G doesn't make extended attributes discoverable, for backup

[vmlemon]

Using NTFS-3G version:

tyson@DESKTOP-6HH5CK9:/mnt/e$ ntfs-3g -v
ntfs-3g: No device is specified.

ntfs-3g 2021.8.22 integrated FUSE 28 - Third Generation NTFS Driver
                Configuration type 7, XATTRS are on, POSIX ACLS are on

Copyright (C) 2005-2007 Yura Pakhuchiy
Copyright (C) 2006-2009 Szabolcs Szakacsits
Copyright (C) 2007-2021 Jean-Pierre Andre
Copyright (C) 2009-2020 Erik Larsson

Usage:    ntfs-3g [-o option[,...]] <device|image_file> <mount_point>

Options:  ro (read-only mount), windows_names, uid=, gid=,
          umask=, fmask=, dmask=, streams_interface=.
          Please see the details in the manual (type: man ntfs-3g).

Example: ntfs-3g /dev/sda1 /mnt/windows

Plugin path: /usr/lib/x86_64-linux-gnu/ntfs-3g

News, support and information:  https://github.com/tuxera/ntfs-3g/

Running on Ubuntu 22.04.3 LTS.

During the process of reporting restic/restic#5111, I noticed that although it was possible to obtain extended attributes, for files that were copied from OS/2 HPFS volumes, under older versions of Windows NT, by manually running getfattr -n system.ntfs_ea, they were inaccessible, by running pax/tar, or Restic, and do not appear, if I attempt getfattr -d , as suggested in that issue report. I also noticed, that the xattr tools do not always reliably interact with them.

With that in mind, whilst I'm unsure if this is by design, or a bug, it would make backing up, and restoring files from NTFS volumes more reliable, and consistent, in terms of data integrity, if this metadata was always exposed via the xattr mechanisms.

[jpandre]

On Linux, the extended attributes sit in several name spaces : user, system, security, ... and the permissions to read or update them depend on the name space. Also "getfattr -d" only shows the attributes in the user name space.

For example, on ext3 as a user :

[linux@optiplex ext3]$ echo foo > bar
[linux@optiplex ext3]$ setfattr -n system.ntfs_ea -v foo bar
setfattr: bar: Operation not supported
[linux@optiplex ext3]$ setfattr -n user.color -v green bar
[linux@optiplex ext3]$ getfattr -d bar
# file: bar
user.color="green"

Now, as root, set a Posix ACL (which is setting system.posix_acl_access) to enable executing by root :

root@optiplex ext3]# setfacl -m u:root:5 bar
[root@optiplex ext3]# getfacl bar
# file: bar
# owner: linux
# group: linux
user::rw-
user:root:r-x
group::r--
mask::r-x
other::r--

[root@optiplex ext3]# getfattr -n system.posix_acl_access -e hex bar
# file: bar
system.posix_acl_access=0x0200000001000600ffffffff020005000000000004000400ffffffff10000500ffffffff20000400ffffffff

[root@optiplex ext3]# getfattr -d bar
# file: bar
user.color="green"

The extended attribute is present in the system name space, but is not shown by "getfattr -d", so ntfs-3g abides by Linux rules.

[vmlemon]

Thanks for the info.

I guess that the only ways of retrieving this metadata, from up the VFS layer, are either explicitly requesting each xattr (I assume this is how SELinux attributes are also supposed to be handled), by name, the mount-time mapping technique, or maintaining a local patch, to expose them, in some other namespace, then?

In any case, I suspect that the Linux kernel devs won't change the behaviour, to avoid breaking things, so I'm unsure how far, down the rabbit hole, to persue this.

In the meantime, the mapping file method gets me most of the way there, for doing one-off backups, of some older NTFS volumes, that contain files migrated from OS/2 HPFS ones.