Samba 4.x package support thread

Samba 4.19.1 is officially out now, and worth mentioning there are 2,047 changes & fixes between 4.18.6 and 4.19.1. Perhaps someone should taking the privilege to do the 4.19.1 PR for OpenWrt?.

1 Like

Let me know if you need helps to test out either compiled Samba 4.19.1 or 4.20-DEV version.

Let me know the platform and architecture and OpenWrt Version if you please.

If I am not mistaken someone a while back in this thread also mentioning MacOS problems, just wanted to help out, perhaps it's already being fixed in after 4.18.6.

Not sure what your issue could be but with 23.05.0 and Samba4 (4.18.6 installed) Network shares are running flawless for me. Getting about 120 MB/s read 110 MB/s write from my WRT32X to my PC and Shield TV, essentially maxes out gigabit lan.

It's with the macOS smb client running that the problem occurs.

Seems both of ../../lib/util/util_net.c & ../../source3/lib/util_sock.c are identical in the source codes version between 4.18.0 through 4.18.6

Incase you haven't tried but have your tried this & this ?

I see there is a macOS fix in 4.19.2. I'm not package maintainer but I suggest just bumping Samba to that at least in main branch, which has all these fixes:

Current version on the package feed (4.18.8) is working flawless for me on my Win11 and Linux PCs, and Shield TV (technically Android is Linux too) though.

Good finds :grinning:, perhaps if there are/is compilation error/s you could try my Samba 4.20-DEV package above. @Gingernut & @phinn feel free to make a PR if you wish.

The only problem is I don't have macOS client to test it out.

1 Like

Nice find indeed.

In my case the router its hostname does not match the name announced with mdns (avahi-dbus-daemon). The hostname 'gw' has an IP address on a maintenance VLAN, whereas the name used for samba on another VLAN is 'nas' with an obviously other address.
Both names are present in DNS (unbound), also for reversed DNS. So adding the appropriate DNS records does not suffice in my case, but the cause could very still be related to naming when using macOS as smb client.

I will try the samba packages in the main branch (possibly also 4.20-DEV) and report back on the results.


Could you post again your link to your version for samba-4.20 of feeds/packages/net/samba4 ? The link you posted before is not valid anymore.

Fixed, sorry for that, need to learn git hehe.

False alarm?

It seems liburing supports is broken as reported in github?.

On Samba4 compilations seems samba4 build system failed to see liburing in :

Checking for liburing package                                                     : not found 
VFS_STATIC: vfs_default,vfs_not_implemented

Normally this will picked up by any build system :

TARGET_LDFLAGS += -Wl,--as-needed -L$(STAGING_DIR)/usr/lib -luring

But not the case with samba4 build system.

[EDIT #3]
Seems fixed, quite hacky I would've have say :

Checking for library uring                                                        : yes 
Checking for io_uring_ring_dontfork in uring                                      : ok 
Checking for header liburing/compat.h                                             : yes 
Checking for struct open_how                                                      : not found 
not building regedit (--without-regedit)
Checking for header ftw.h                                                         : yes 
Checking for nftw                                                                 : ok 
mingw not available, not building winexe
Checking for library crypto                                                       : yes 
Checking for DES_pcbc_encrypt in crypto                                           : ok 
Checking for glib-2.0                                                             : yes 
Checking for header glib.h                                                        : yes 
Checking for library glib-2.0                                                     : no 
Checking for 'tracker-sparql-2.0'                                                 : not found 
Checking for 'tracker-sparql-1.0'                                                 : not found 
Checking for 'tracker-sparql-0.16'                                                : not found 
Checking for 'tracker-sparql-0.14'                                                : not found 
Checking for header rpc/types.h                                                   : yes 
Checking for header rpc/xdr.h                                                     : yes 
Checking for library nscd                                                         : no 
Checking for nscd_flush_cache                                                     : not found 
VFS_STATIC: vfs_default,vfs_not_implemented,vfs_posixacl
VFS_SHARED: vfs_io_uring,vfs_fruit,vfs_shadow_copy2,vfs_recycle,vfs_fake_perms,vfs_readonly,vfs_cap,vfs_offline,vfs_crossrename,vfs_catia,vfs_streams_xattr,vfs_xattr_tdb,vfs_widelinks,vfs_btrfs,vfs_virusfilter,vfs_shell_snap,vfs_commit,vfs_worm,vfs_netatalk,vfs_dirsort,vfs_fileid,vfs_audit,vfs_extd_audit,vfs_full_audit,vfs_acl_xattr,vfs_acl_tdb
PDB_STATIC: pdb_smbpasswd,pdb_tdbsam,pdb_samba_dsdb,pdb_ldapsam
AUTH_STATIC: auth_builtin,auth_sam,auth_unix,auth_samba4
AUTH_SHARED: auth_script

Probable fixes :

TARGET_LDFLAGS += -Wl,--as-needed -L$(STAGING_DIR)/usr/lib -luring

cat 119-fixing-liburing.patch for patches folder as always :

diff -Naur a/source3/wscript b/source3/wscript
--- a/source3/wscript	2023-10-23 18:43:36.874608200 +0700
+++ b/source3/wscript	2023-10-24 17:03:14.246488400 +0700
@@ -1720,8 +1720,7 @@
     if conf.CHECK_CFG(package='liburing', args='--cflags --libs',
                       msg='Checking for liburing package', uselib_store="URING"):
-        if (conf.CHECK_HEADERS('liburing.h', lib='uring')
-                                      and conf.CHECK_LIB('uring', shlib=True)):
+        if (conf.CHECK_HEADERS('liburing.h', lib='uring') and conf.CHECK_LIB('uring', shlib=True)):
             conf.CHECK_FUNCS_IN('io_uring_ring_dontfork', 'uring',
             # There are a few distributions, which

Just use or try my Samba 4.20-DEV package if you want to see if later/latest version has better compatibilities with macOS as a client.

1 Like

Found out somekind of relationship between UTF8_NORMALISATION and libicu usage in SAMBA4 that might interrupting macOS interoperabilities as a client (most probably). Please try to use Samba 4.20-DEV Revision #3.

I tried the 119-fixing-liburing.patch:
No change; same error.
The patch was applied according to the build log, but the generated seems to be identical to the old one. I didn't compare the other files.

Does the resulting compiled libraries is identically nearly exact the same or there are many parts that are different?. You could use software like beyond compare to compare the hex comparison if you are using Windows also.

What Samba4 version did you have compiled?.

Did you also apply this line in the Samba4 Makefile :

TARGET_LDFLAGS += -Wl,--as-needed -L$(STAGING_DIR)/usr/lib -luring

Any chances to share your samba config so I can try to replicate the errors and environments?

119-fixing-liburing.patch does nothing; the patch only changes a split line into one

Yup, sorry for that, if you take a look at the history of edit (first one), my patch was :

diff -Naur a/source3/wscript b/source3/wscript
--- a/source3/wscript
+++ b/source3/wscript
@@ -1720,8 +1720,6 @@
     if conf.CHECK_CFG(package='liburing', args='--cflags --libs',
                       msg='Checking for liburing package', uselib_store="URING"):
-        if (conf.CHECK_HEADERS('liburing.h', lib='uring')
-                                      and conf.CHECK_LIB('uring', shlib=True)):
             conf.CHECK_FUNCS_IN('io_uring_ring_dontfork', 'uring',
             # There are a few distributions, which

Turn out some probably some how my build host environments variables somehow got clouded with something which caused my liburing not being detected, really sorry for these.

(Unrelated to uring bug.)
I have a commit that needs testing. It adds iconv support in samba if OpenWrt is built with full iconv support.

I'm looking for volunteers that build their own OpenWrt with / without full iconv support and have files with national characters in their name (stored in codepage, as Windows does, not in unicode/utf-8).
Please build with this patch report if any errors. Also please report if this patch increases the size of samba when built without full iconv. ($(ICONV_DEPENDS) might add something, but I'm not sure.)

1 Like

there is a pull request pending for wsdd2
witch for me fixes the use of samba showing up in windows 10/11
I encourage people to test comment and support this pull request
it world be good encourage movement on this

1 Like

@Gingernut since you a few weeks ago, I finally moved my network over to the MT6000 and ran some tests. Using Samba 4.18.8 (latest available in OpenWrt) average of 3 tests each target read/write 5GB in files:

  1. WRT32X - Read: 102 MB/s, Load%: 95/18. Write: 106 MB/s, Load%: 92/21.

  2. GL-MT6000 - Read: 85 MB/s, Load%: 13/8/32/5. Write: 112 MB/s; Load%: 30/24/26/12.

Conclusions: using "Enable Extra Tuning" no difference was observed on either target so left it off. Interestingly the 85 MB/s read on MT6000 seems like a hard limit it sat there pegged on several tests. Maybe a tuning parameter somewhere can improve that. USB3 SSD was mounted with kmod-usb-storage-uas (uas drive seems to be required by this target).

So in general the 7 year old mvebu is actually a little faster, but leaves nothing in CPU0 for anything else which is not ideal. A surprise, but it's known to be a performant platform. Coincidentally WRT32X is more consistent with SQM results too which I might post about elsewhere.

1 Like

I observe the same unexpected low 75-80 MB/s read speed (writing at 110-115 MB/s @20-30% CPU load) no matter if the filesystem is f2fs, ext4 or exfat, on my QNAP QHora-301W with USB3 SSD connected to the USB3 port.
I'm using fully NSS (including NSS wifi offload) accelerated build for IPQ807X.
Sandisk SSD mounted using ksmbd in my case. This SSD can write/read at above 1000 MB/s if connected to a PC directly.
So definitely there is something wrong. I don't think it's a hardware limitation.