vesqute

Well, as always, ASPM was the culprit, full speed both ways with it deactivated... Couldn't reproduce the problem. Been pushing files back and forth using SMB and running the speedtest docker without any problems. Have you tried a different (live) distro to make sure it's software and not hardware?

Found some time today to put a second card in my workstation (quite annoying on an ITX build) to test throughput: Unraid -> workstation: full speed Workstation -> Unraid: about 1 Gbit Workstation -> Ubuntu Live (instead of Unraid): about 7 Gbit Clearly the driver doesn’t play all that nice with Unraid (7.2.3 here) yet. I’ll test some more and the SpeedTest docker later.

ASPM enabled or disabled? Link drops are a known problem with the r8125 NICs with ASPM enabled, might also happen with the r8127. With the r8125 disconnecting/connecting the cable or disabling/enabling the port (switch or server side) would bring the link back up.

Thanks to ich777 and jinlife compiling the r8127 driver is incredibly easy: Just grab jinlife's repo (GitHub link) and compile it in ich777's unraid_kernel docker (GitHub link). Result: https://github.com/vesqute/unraid-r8125-r8152-driver The unraid-r8127.plg installed fine for me and the card works, though I haven't done any further tests yet. To activate ASPM, add this as Modprobe config to the driver under Tools -> System Drivers: options r8127 aspm=1 Result in AutoTweak:

Don't really know where to post this, but I'll try here, since it's exclusive to rclone mounts... Because of some new iPads in the family I had to activate "Enhanced macOS interoperability" in the Unraid SMB settings, since then Windows clients can't rename or delete files on my shared rclone mounts. Encrypted GDrive mounted with: rclone mount --allow-other \ --umask 000 \ --dir-cache-time 1000h \ --attr-timeout 1000h \ --log-file=/mnt/cache/rclone/log.txt \ --log-level INFO \ --poll-interval 10s \ --cache-dir=/mnt/cache/rclone \ --drive-pacer-min-sleep 10ms \ --drive-pacer-burst 1000 \ --vfs-cache-mode full \ --vfs-read-ahead 1G \ --timeout 1h \ --rc \ gcrypt: "/mnt/gcrypt" & Then in an user share is a symbolic link to that mount. No problems on the Windows clients with "Enhanced macOS interoperability" deactivated. With it activated I get "Error 0x80070032: The request is not supported." when trying to delete or edit a file. No Problems with files that aren't on an rclone mount. No errors in the rclone log, not even with log-level DEBUG. No errors in the Unraid system log. Is there a way to fix this? Edit: The problem still exists, but I found a way to get around it in my case. After figuring out what "Enhanced macOS interoperability" actually does and reading up on vfs_fruit, it was obvious, that this can be changed on a per-share-basis. I don't really understand why Unraid doesn't allow this... Leaving "Enhanced macOS interoperability" deactivated and putting the vfs_fruit config in the "Samba extra configuration" to only have it active for a single share works. I just have a new "non-rclone" share for all Apple devices now. Created a share (named "Apple") and deactivated export in it's settings. Extra configuration, with "Apple" as public share: fruit:aapl = yes fruit:resource = file fruit:metadata = netatalk fruit:locking = none fruit:encoding = native fruit:nfs_aces = No [Apple] vfs objects = catia fruit streams_xattr path = /mnt/user/Apple comment = browseable = yes # Public public = yes writeable = yes case sensitive = auto preserve case = yes short preserve case = yes