Paragon NTFS3 driver backported to OpenWrt 5.10 kernel - how to test

Possibly driver has problems with endianess, so looks like bug to report

I haven't tested these honestly but ntfs-3g works, exfat works, everything else seems to work fine.

Then I'd have to concur with @lukasz92

Good catch - I thought the N13U was big endian too, but I see now it's mipsel. I don't have any big endian devices myself so I can't test.

As an aside, if it is an endian issue, than that disappoints me in Paragon a little. I'd expect more out of a driver as mature as this one.

Damn CTC and the Datapoint 2200. :stuck_out_tongue:

Anyone else have a big endian device?

It seems there's a patch available for this issue, not sure
if it will help on this matter.

1 Like

I can confirm the above patch solves this issue for my device. I can now plug and play mount ntfs partition with ntfs3 on my 1043nd, no more errors.

Thanks a lot for the help...

1 Like

I was wondering what mount options you guys are using. I'm on defaults for now and there seems to be some issue with drive permission. Such issue wasn't present in exfat nor in ntfs-3g How do you deal with this?
I'm using ksmbd server and I have to force root on the mounted partition to get write access, otherwise it's on read only mode.

I'm using the stock mounting system in LUCI, which defaults to these mount flags: rw,relatime,uid=0,gid=0,iocharset=default

I used ksmbd for a while and ran into issues with compatibility with Windows. Getting the initial connection to work was painful. Once I did it would work for a while, and I'd think great it was just a glitch, but then an hour later I'd try to connect and have all sorts of issues again. I gave up on it and use Samba 4 with smbpasswd-configured users. I have no permissions issues with it. You can configure the create and directory mask with it right in LUCI.

That's weird, it was quite the opposite for me to set it up. I had the same permission issues with samba3 which is why I switched it over to ksmbd at that time. I can't install samba4 due to low storage space also I don't wanna set up exroot just for it.

Right now I'm using defaults,noatime,prealloc,force as mount options. And running ksmbd with forced root. I'm still experimenting with it so it's fine for now.

Sorry for the absent.

I've create a branch with these 3 patches included. Feel free and try it. I'm current on a MT7621 box which is working fine.

I'm using iocharset=utf8,prealloc as my drive has some CJK filenames.

1 Like

Thanks, I already compiled an image with those patches and it did the trick. Been over a week and
it's running smooth ever since.

Before the patches, I couldn't mount the partition no matter what I did. At the same time it worked fine on my other device which is little endian. So as mentioned by lukasz92, it was an issue with endianess.

1 Like

Hi, I tried to compile this patched ntfs3 on rockchip rk3588, but got some error:

rock@rock5b:~/openwrt-ntfs3/kernel/ntfs3/src$ make -C \
> /lib/modules/5.10.110-34-rockchip-gca15bbe36e6c/build \
> M=/home/rock/openwrt-ntfs3/kernel/ntfs3/src \
> modules
make: Entering directory '/usr/src/linux-headers-5.10.110-34-rockchip-gca15bbe36e6c'
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/attrib.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/attrlist.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/bitfunc.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/bitmap.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/dir.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/fsntfs.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/frecord.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/file.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/fslog.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/inode.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/index.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/lznt.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/namei.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/record.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/run.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/super.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/upcase.o
  CC [M]  /home/rock/openwrt-ntfs3/kernel/ntfs3/src/xattr.o
/home/rock/openwrt-ntfs3/kernel/ntfs3/src/xattr.c:989:9: error: initialization of 'int (*)(const struct xattr_handler *, struct dentry *, struct inode *, const char *, void *, size_t,  int)' {aka 'int (*)(const struct xattr_handler *, struct dentry *, struct inode *, const char *, void *, long unsigned int,  int)'} from incompatible pointer type 'int (*)(const struct xattr_handler *, struct dentry *, struct inode *, const char *, void *, size_t)' {aka 'int (*)(const struct xattr_handler *, struct dentry *, struct inode *, const char *, void *, long unsigned int)'} [-Werror=incompatible-pointer-types]
  989 |  .get = ntfs_getxattr,
      |         ^~~~~~~~~~~~~
/home/rock/openwrt-ntfs3/kernel/ntfs3/src/xattr.c:989:9: note: (near initialization for 'ntfs_other_xattr_handler.get')
cc1: some warnings being treated as errors
make[1]: *** [scripts/ /home/rock/openwrt-ntfs3/kernel/ntfs3/src/xattr.o] Error 1
make: *** [Makefile:1920: /home/rock/openwrt-ntfs3/kernel/ntfs3/src] Error 2
make: Leaving directory '/usr/src/linux-headers-5.10.110-34-rockchip-gca15bbe36e6c'

I highly recommend using xymopen's feed rather than patching directly any more,.

Thank you for your reply.
Actually, I am using the patched NTFS3 source code from xymopen.
But I tried to compile it for the Rock 5B development board ( with rk3588 soc), which also has kernel 5.10.
I tried to modify the ntfs_getxattr function in the code to be compatible with the api and it works fine for now.
I just wonder why it compiles properly on openwrt but not on debian when they also have kernel 5.10.
By the way, why don't you recommend enable the "NTFS POSIX Access Control Lists"?

I ran into difficulty backporting that to 5.10 and intended to work on it later. I've subsequently moved to kernel 5.15+ in OpenWrt myself, so haven't had the impetus to push this patch any further. Especially since the OpenWrt maintainers had no interest in including it.

Thanks for all your hard work!