GL-AXT1800 : Error -50 when copying files to a shared (exfat) disk on Mac OS

Hello. I’m getting the -50 error when I try to copy a file to the shared (exfat) disk on Mac OS with the GL-AXT1800. Can you help me resolve this issue?

What version of firmware do you have?

Latest - 4.2.0 release3

I also tried the shared SD card and I have the same problem as with USB. (tested on an M1 Ventura and Intel Mojave)… Any idea?

Hello,

About two weeks ago, I contacted you about a problem I am having when copying files to a shared drive (exFAT) with my two Macs. Every time I try to copy files, I get the error -50. I have done a test on a PC, and everything works fine. So it seems that the problem is an incompatibility with Macs. It’s a pity, because this feature is one of the main reasons why I chose this product. Could you suggest a solution? Or, failing that, could you reply to this message to confirm that you are working on the problem? I haven’t heard from you since my response to your previous question.

I too have this issue, reported back in Sept 2022. Only happens with MacOS. There has never been a solution. Windows works fine with the Samba SD share

Try on your Mac:
sudo -s
echo “[default]” >> /etc/nsmb.conf
echo “signing_required=no” >> /etc/nsmb.conf
exit

1 Like

Updated the .conf file, restart Mac and still same issue

I appreciate your attempt to help, diver68, but as MusclePuptoy mentioned, the solution isn’t effective. I urgently need a resolution for this pressing issue and cannot afford to wait months for a fix. As this is a key feature that you promote, kindly provide support in finding a functional resolution.

Same issue here with my macbook pro. can’t get anything to copy. Should be this hard use this Beryl, and I am returning back to amazon. too bad, I’ve had such a bad experience with this MT3000 in a macos environ, I won’t try their products again.

I have AXT1800, same problem with accessing the exFAT SD Card from MacOS.

Tried both disable and enable vfs fruit+stream_xattr. If I disable it, MacOS will create the AppleDouble file manually. Looks like MacOS will always use extended attributes now, and can't be disabled, this is where the problem come from.

If I disable all vfs module, I get error from exfat-fs:
exFAT-fs (sda1): error, failed to bmap (inode : 900dc698 iblock : 0, err : -5)

If I enable vfs module, I get error from AFP_AfpInfo,
fruit_pwrite_meta_netatalk: ad_pwrite [filename:AFP_AfpInfo] failed

If I pass the AfpInfo meta data to stream_xattr module, by setting fruit:metadata = stream, I get:
fruit_pwrite_meta_stream: On-demand create [filename:AFP_AfpInfo] in write failed: No such file or directory

I am very stuck right now, as all three methods have failed. Any sugguestions?


Firmware: 4.5.16 Rel 2
Samba: 4.14.12
kmod-fs-exfat: 4.4.60+5.12.3-2

Format the SD using ext4 - exFAT does not support the necessary attributes.

Thanks for the prompt reply.

True, exFAT does not support the necessary attributes, but as I said in my last post, the MacOS can create and manage the extended attribute via the AppleDouble ._ file. from the client side. (This is how MacOS does it if you put the exFAT SD Card straight into a Mac.)
To proof my point, I formatted my SD Card to FAT32, and disabled the vfs fruit+xattr module again:
#vfs objects = catia fruit streams_xattr

Now I could access the SD Card. And the AppleDouble ._ was created correctly.

This proofs that the current kmod-fs-exfat is buggy and can't handle the "._" file. If you pull-in the updated kmod-fs-exfat from the main OpenWrt repository, we might be able to have a quick fix for now. This can be done without updating the entire Samba library.

Thanks!

@bruce That's an case for you :wink:

1 Like

Hello @bruce and other GL-iNet support staff:

After more digging, I come to the conclusion that the kmod-fs-exfat (4.4.60+5.12.3-2) module included in AXT1800 is too old.
I had an old A1300 router, so I took it out and flashed with the lasted firmware (4.5.16-0321-1711027287), disabled vfs fruit/stream_xattr with:
#vfs objects = catia fruit streams_xattr
#fruit:aapl = yes
#fruit:nfs_aces = no
And Bang! I can access the exfat sd card and with extended attribute and AppleDouble ._ file working too.

So I checked the kmod-fs-exfat module shipped with A1300, and it was newer than my AXT1800!

The version on the A1300 is: 5.4.179+5.12.3-1

Can I request that GL-iNet to update the kmod-fs-exfat package on the AXT1800 and in the repository (Maybe the MT3000 too, since I don't have this router) so we can have access to the SD Card back again.

As SD cards are relatively slow, and not many users are using this router in a critical NAS operation, it's not neccessary to achieve maximum speed offered by vfs_fruit. This default samba setting (without vfs_fruit) should work with ext4 formatted card as well. If GL-iNet can update kmod-fs-exfat and set vfs_fruit default to disabled, then we will get maximum compatibility with different formats of SD card. Until the samba-exfat module is fixed in OpenWrt.

Thanks!


AXT1800
Firmware: 4.5.16 Rel 2
Samba: 4.14.12
kmod-fs-exfat: 4.4.60+5.12.3-2

I don't understand a word of what @dchao is saying, but after more than a year of frustration, all I can say is @bruce, please do it (for exfat) !

@dchao, you are a gift from heaven :heart:

Basically our AXT1800 is still using a very old kernel which has a bug in the exfat software that prevents MacOS accessing it. I took out my older GL-A1300 router, that has the latest kernel, and can access the exfat formated sd card without any problem.

1 Like

I can't wait to being able to do it too :))

I hope GL-iNet engineers can take a look at the problem seriously, and fix the bug ASAP. I believe the fix is simply compile in the new kernel.