Please add/create a port for Samba 4.16 both 4.12 and 4.13 have been discontinued by the Samba team.
I request this too
fwiw, https://github.com/truenas/ports/tree/truenas/13.0-stable/net/samba
I was hoping there is an attachment :) The problem with the post 4.14 is that VFS interface has changed noticeably and changes in the ports modules require thorough testing/checking... So, if someone would like to give me a hand on that - it'll be much appreciated.
(In reply to Timur I. Bakeyev from comment #3) I looked into the port Makefile and almost started to try due to the complexity. I am willing to test. I run Samba only for file services, no DC or else.
(In reply to Timur I. Bakeyev from comment #3) Thanks for the explanation why newer Samba versions haven't made it into ports.
(In reply to Timur I. Bakeyev from comment #3) Where are the port attachments for testing?
From comment #2 it seems TrueNAS has a fork for samba and that's the source of their port: https://github.com/truenas/samba , the development is still active in the branches. It would be a good base for check the diff and backport the samba port. For easier to access the truenas 4.15 port, I grab it, did some very minor modifications and put to: http://people.freebsd.org/~lwhsu/tmp/samba415.tgz Please note that this currently will fail in configure stage. Perhaps we can ask https://github.com/anodos325 for collaboration?
Related ports https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257442 (tevent) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257432 (talloc) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257528 (tdb) - Please read comments Note, not sure why we aren't using LDB from ports in our current Samba ports?
(In reply to Timur I. Bakeyev from comment #3) After reviewing the man pages for stat, fstat, openat, getfh and https://wiki.samba.org/index.php/The_New_VFS via https://www.samba.org/samba/history/samba-4.14.0.html I can see that this is by no means a trivial endevour. Unfortunately I have NO knowledge of Linux, though I'm happy to test Samba as AD and as fileserver (On FreeBSD 12.3-Stable). Do you have a location for material that we can/should draw from for testing? PS I'm stuck on UFS2 due to our use of MAC_BIBA
(In reply to Daniel Engberg from comment #8) Can those ports be updated before the samba update or does that need to happen in lock-step ?
(In reply to Kurt Jaeger from comment #10) As far as I can tell they should be fine (needs proper runtime testing) but I'm not sure however how version dependant ldb is. I've only briefly tested Samba 4.13 (without ldb support) and it seems to work but it would be nice if a few others also could test, Timur might also have some valuable input regarding this.
(unsure if that helps...) I tried to check what i can do. I could compile samba 4.15.7 from git upstream with a little patch (include <time.h> in lib/util/time.h) and CC=gcc11. Unfortunately i could not get any 4.16.x version to compile. It was this bug in the samba bugzilla (4.16.x) https://bugzilla.samba.org/show_bug.cgi?id=15030
(In reply to georg-bsd from comment #12) Can you provide the net/samba415 of the stuff that you got to compile ?
This was my "patch" git diff diff --git a/lib/util/time.h b/lib/util/time.h index bdb67de5431..8b61e41ae94 100644 --- a/lib/util/time.h +++ b/lib/util/time.h @@ -27,6 +27,7 @@ #include <stdbool.h> #include <stdint.h> #include <talloc.h> +#include <time.h> #ifndef TIME_T_MIN /* we use 0 here, because (time_t)-1 means error */ git describe samba-4.15.7 I compiled with: sudo pkg install git gcc11 py38-iso8601 py38-pyasn1 p5-parse-yapp devel/icu bison python3 pkgconf lmdb gnutls gpgme jansson openldap24-client py38-markdown py38-dnspython popt py38-cryptography make distclean && ./configure CC=/usr/local/bin/gcc11 CFLAGS="-I/usr/local/include" --enable-selftest && make -j16 && make quicktest The selftests did not run successfully. I tried that also on linux and they failed like on freebsd. Not sure if i did anything wrong .... I guess if you try to use this, you can remove the enable-selftest option.
There is an interesting thread on ports@freebsd.org about this topic: https://lists.freebsd.org/archives/freebsd-ports/2022-June/002119.html The maintainer Andrew Walker <awalker@ixsystems.com> of TrueNAS/Samba ports also responded, but I don't find this mail in the ports archive: On Tue, Jun 21, 2022 at 3:44 AM Patrick M. Hausen <hausen@punkt.de> wrote: Hi all, > Am 19.06.2022 um 12:52 schrieb Ronald Klop <ronald-lists@klop.ws>: > iXsystems ported Samba 4.15 for TrueNAS. I don't know why they did not try to get that into the regular ports tree or how much effort it took them to accomplish this. I'll cc the maintainer of them. Our port of samba may not be 100% appropriate for upstreaming. For instance, we do not build with the AD DC role and we have custom vfs modules that are not tested against the variety of configurations that FreeBSD users might have. I'm happy to make a quick update of the FreeBSD port to 4.15 or 4.16 if Timur is no longer maintaining it. Andrew
Created attachment 234861 [details] database/tdb version 1.4.4
Created attachment 234862 [details] devel/talloc: Version 2.3.3
Created attachment 234863 [details] devel/tevent: 0.11.0
Created attachment 234864 [details] net/samba415 This patch does not yet fully compile. I dont know how to fix this last issue I dont know how to fix this issue
I mostly got the port for samba4.15.7 finished but i cant fix the last problem. I added patches for the required libraries and my WIP version of samba415. 4169/4177] Compiling source4/lib/registry/man/regshell.1.xml runner ' true --xinclude -o source4/lib/registry/man/regshell.1 --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl ../../source4/lib/registry/man/regshell.1.xml ' [4170/4177] Compiling source4/lib/registry/man/regtree.1.xml runner ' true --xinclude -o source4/lib/registry/man/regtree.1 --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl ../../source4/lib/registry/man/regtree.1.xml ' [4171/4177] Compiling source4/utils/oLschema2ldif/oLschema2ldif.1.xml runner ' true --xinclude -o source4/utils/oLschema2ldif/oLschema2ldif.1 --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl ../../source4/utils/oLschema2ldif/oLschema2ldif.1.xml ' [4172/4177] Compiling source4/torture/man/smbtorture.1.xml runner ' true --xinclude -o source4/torture/man/smbtorture.1 --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl ../../source4/torture/man/smbtorture.1.xml ' [4173/4177] Compiling source4/torture/man/gentest.1.xml runner ' true --xinclude -o source4/torture/man/gentest.1 --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl ../../source4/torture/man/gentest.1.xml ' [4174/4177] Compiling source4/torture/man/masktest.1.xml Waf: Leaving directory `/wrkdirs/usr/ports/net/samba415/work/samba-4.15.7/bin/default' Build failed -> missing file: '/wrkdirs/usr/ports/net/samba415/work/samba-4.15.7/bin/default/lib/ldb/man/ldb.3' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/net/samba415
Created attachment 234865 [details] devel/tdb: 1.4.6
Created attachment 234866 [details] net/samba: 4.16.2 mostly compiles This patch mostly compiles samba 4.16.2 but suffers the same problem as my 4.15.7 patch .....
samba 4.16.2 is also mostly compiling with small changes to my previous port but suffers the same problem .... maybe someone could help me out about this.... [4426/4435] Compiling source4/lib/registry/man/regpatch.1.xml runner ' true --xinclude -o source4/lib/registry/man/regpatch.1 --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl ../../source4/lib/registry/man/regpatch.1.xml ' Waf: Leaving directory `/wrkdirs/usr/ports/net/samba416/work/samba-4.16.2/bin/default' Build failed -> missing file: '/wrkdirs/usr/ports/net/samba416/work/samba-4.16.2/bin/default/lib/ldb/man/ldb.3' ===> Compilation failed unexpectedly.
georg-bsd, thanks for your patches but don't attach patches for dependencies since they're unrelated to the bug report. Create separate PRs (if needed) and in this case they're are also duplicates (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263874#c8 ). Best regards, Daniel
Created attachment 234871 [details] net/samba416: Compiles Compiles but pkg-plist.(python|ad_dc|cluster) not ok. I know too less about the single samba components to sort them out. I updated the man pages and the build dependencies. The regenerated man pages make this patch bigger than 1 MB so i attached it as a tar.gz. I also disabled all patches from freebsd to make it compile. Also the vfs-freebsd! My goal was to setup a "base" from where to step forward. Maybe someone with more experience what belongs where can sort the pkg-plists ....
This patch needs the patches from Daniel Engberg #8.
Created attachment 234872 [details] net/samba416: Patch part 1/2 as text
Created attachment 234873 [details] net/samba416: Patch part 2/2 as text
Is this still an ongoing effort? I haven't seen any updates to this PR in over a month. I'm willing to throw a virtual machine at this to help test it. I use FreeBSD + ZFS + Samba in production, but the unsupported samba port is causing problems that may force me to migrate to Linux + ZFS + Samba (not to knock Linux, but given the dependencies that have evolved over the last 11 years, I'd rather help contributed to update Samba than I would migrate from FreeBSD to Linux).
(In reply to johnllyon from comment #29) What do you actually expect? It is a very complex project and it takes a lot of time to accomondate the port upgrade. If you are really willing to help out, try to contact the port maintainer directly and offer your help. Everyone will appreciate, including me!
As i wrote: I need help to get the port finished. Its building but pkg-plist.(python|ad_dc|cluster) not ok. I know too less about the single samba components to sort them out.
I don't want to rush things up, but all be aware CVE's for samba are growing and we are still unpatched. CVE-2022-2031, CVE-2022-32742, CVE-2022-32744, CVE-2022-32745 and CVE-2022-32746.
(In reply to Dutchman01 from comment #32) I applied the patches to 4.13 and I've been running them for a almost a week in several sites without problems. You can find them here: https://www.netfence.it/sub/sambaonfreebsd/ I know this should be a different bug, but I'd like others to test them, before submission. If you are daring enough... :)
Ok, if anyone was wondering. I got samba416 that compiles for most of the setups, but, unfortunately, vfs_streams_xattr and vfs_freebsd got the API fully changed and require more work to be brought up-to-date. So, I'm hesitating, either to release the port without those two(ok, one) modules being compatible with the old samba413 or release it now and add missing functionality either. Was thinning about resurrecting samba4-devel as an alternative to samba416 for now... So, what are your thoughts? With best regards, Timur
(In reply to Timur I. Bakeyev from comment #34) Fantastic. Why not make a "samba-devel" port and stabilize. Then you can move it to samba416?
(In reply to Timur I. Bakeyev from comment #34) I'm using vfs_streams_xattr on only one server and vfs_freebsd on none. So going ahead with a samba416 port would suit 95% of my use cases. I'll look forward to getting this on the last server, but I'd happily start testing in the meanwhile.
To make it makes sense to put it under net/samba416 even if its not "fully featured yet". I associate -devel with beta/development branches from upstream which this port is not based on. The new port will be a port of version 4.16.
Just use pkg-* to tell ("message") users needed information I agree with others that we should avoid -devel or similar ports. Great work Timur!
(In reply to Dries Michiels from comment #37) This is a good idea with pkg-message. Timur, please add the purpose of these VFS modules since I guess it is not directly obvious what they are used for. I know that Samba uses xattr to store DOS attributes.
I've backported a number of patches to net/samba412 so that it builds in DPorts (2022Q3). Just in case somebody wants to give it a go in FreeBSD Ports: https://github.com/DragonFlyBSD/DeltaPorts/commit/2bc2d1f517ba8476b No testing whatsoever has been done but I'm happy to test it if anybody knows how to do it. Also, if anybody wants to test it themselves, I'm happy to help too.
(In reply to Antonio Huete Jimenez from comment #40) Sorry, wrong ticket.
(In reply to Michael Osipov from comment #39) I think you'll find that man vfs_freebsd is your friend. Briefly, it is required for samba4 to run within a jail context, where I run multiple samba instances. Timur, issuing a samba-devel is a good idea. Gets 416 out to the world, and we can contribute with the extattr mappings.
(In reply to dewayne from comment #42) Thanks for the pointer. It is not jails, Samba uses xattr to store DOS attributes. I so guess without this module one cannot reasonbly use it at all, no?
(In reply to Michael Osipov from comment #43) Actually no. As I said, I'm using vfs_streams_xattr on one installation out of about 25 (that's where I have Mac clients, although they could eventually live without, anyway). On all other installations, I don't care about extended attributes. YMMV.
Sorry for the silence again, while new port builds nicely with no errors I have troubles to make Samba work with anything beyond just simple file sharing with just nmbd/smbd and even that only with Windows... Something is really wrong there, in particular with ZFSACLs. I'm trying to find the solution together with Andrew Walker, who successfully brought 4.15.4 to the TrueNAS, but that may take some more time. Meanwhile I guess I'd take Michael's suggestion to re-populate samba4-devel, so you have something to play with meanwhile. P.S> If there is someone good in Git-Fu I can really take some help in mastering proper patchsets...
Any updates to this? FWIW, stripping optional modules/features to get something supported in the tree seems like a good way to go, considering the current state. There's even precedent for it, such as Python 3 and PHP 8 being added before feature parity existed with their respective predecessors.
I'm fighting with the last small, but essential bit in regards of proper placing procfs mountpoint. The bad(?) news is that Samba beyond 4.13 will run only on FreeBSD 13.1+ due the hard requirement for procfs with `nodup` option. Well, maybe there is a way to lift that requirement with more thorough code audit, but at the moment that's the only solution, for which we'd thank Andrew Walker and iXsystems.
(In reply to Timur I. Bakeyev from comment #47) Thanks for the update Timur. We removed procfs from our builds long ago (1997). As we'll need to reinsert "device PROCFS" into kernel configs, will we also need "options LINPROCFS"? I ask because the man procfs (for 13.1) states: "This [procfs] functionality is deprecated. Users are advised to use libprocstat(3) and kvm(3) instead." ref: https://www.freebsd.org/cgi/man.cgi?query=procfs&sektion=5&apropos=0&manpath=FreeBSD+13.1-RELEASE+and+Ports Perhaps the man procfs isn't yet in sync with https://cgit.freebsd.org/src/tree/sys/amd64/conf/GENERIC?h=stable/13 https://cgit.freebsd.org/src/tree/sys/amd64/conf/GENERIC which do not have "option LINPROCFS" For those that remain on 12.x series is there a mechanism to retain samba4.13 in the ports tree? Or should we plan on creating a self-managed "local" category for samba4.13 and its required versions of ldb tbd, tevent, talloc? (an ugly stop-gap). For those with a security focus, this may interest https://hardenedbsd.org/article/shawn-webb/2014-10-15/hardening-procfs-and-linprocfs After reading georg-bsd's patches I better appreciate the huge effort that this requires. Pity the samba team don't use a real OS for SAMBA development/support ;-}
(In reply to Timur I. Bakeyev from comment #45) Apologies if you already know this. For our functioning AD on SAMBA 4.13 on FreeBSD 12.3S with ufs inside a jail we have: bind interfaces only = Yes server role = active directory domain controller server services = s3fs, rpc, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate idmap_ldb:use rfc2307 = yes vfs objects = dfs_samba4 freebsd acl_xattr acl_xattr:ignore system acls = yes acl_xattr:default acl style = windows and the SAMBA 4.13 fileshare runs on the same physical box bind interfaces only = Yes security = ADS kerberos method = system keytab kerberos encryption types = strong reject md5 servers = yes require strong key = yes winbind use default domain = yes otherwise usual rfc2307 setup per samba website guidance.
If you feel adventurous, you can try to fetch and build port from: https://gitlab.com/samba-freebsd/ports/net/samba416 It's ALMOST Ok, at least I hope so :)
(In reply to dewayne from comment #48) Byte me, all what I said about `procfs` is actually related to `fdescfs` :D I guess I was staring too long on the Samba code, which is using procfs to obtain the relevant information... The relevant discussion is here: https://reviews.freebsd.org/D30140 and https://reviews.freebsd.org/D30131
(In reply to dewayne from comment #48) The theory says that new VFS code should still work with older versions of the FreeBSD, just much slower. Unfortunately practice shows that it's not working besides very basic fileserver mode, without usage of stream_xattrs module and zfsacl. It could be that the missing fixes are pretty trivial, but as I'm piggy backing here iXsystems I don't have a ready solution on hands. I guess ATM it's better to provide version that works at least on 13.1+ and investigate support of the legacy OS versions later.
(In reply to dewayne from comment #49) Oh, your setup is quite far from the popular one, which reminds me to fix vfs_freebsd module as well :( I honestly wrote it from scratch solely myself, but now looking on the code I'm getting puzzled - what it is all doing :D Well, I know that does it do, but need to adapt it to the new API.
Looks like 0026-vfs-add-a-compatibility-option-to-the-vfs_streams_xa.patch has some issues. It's inserting what appears to be git rebase/merge conflict lines? I'm guessing you don't want to include that at all? streams_xattr_fcntl exists and is the same as the patch?
(In reply to Timur I. Bakeyev from comment #53) Re: reply 52 - that's reasonable. I'll remain on 12 until eol due to the large number of changes and patching that's occurred with 13. re: reply 53. Basicially samba uses the extended attribute EXTATTR_NAMESPACE_SYSTEM which prohibited SAMBA's function within a jail. Your fix tied all extended attributes to the EXTATTR_NAMESPACE_USER, via SAMBA's vfs mechanism. :) The alternative is to modify lib/replace/xattr.c's to change attrnamespace from either EXTATTR_NAMESPACE_SYSTEM or EXTATTR_NAMESPACE_SECURITY (which I don't think is used) to EXTATTR_NAMESPACE_USER. (I have a simple patch, but don't wish to distract from the bigger picture of this thread. IThough if it saves you some effort,I'm happy to share.). Thankyou for the pointer in reply 50 which I'll try next weekend, I'm sure others are happy for the opportunity.
(In reply to Timur I. Bakeyev from comment #52) I agree on providing a port that works on 13.1 as a first step: surely that's better than nothing. Also, working on 12.3, albeit slower or only in some cases, is better than not working. How much work would porting these changes to a future 12.x be? How much likely would it be, that this could happen? (Of course "zero chance" is an accettable answer).
From a macOS 12.6 VM in Virtual Box on a macOS and a FreeBSD 13.1 guest on a FreeBSD 13.1 host running net/samba416 removing the streams_xattr_fcntl function from 0026-vfs-add-a-compatibility-option-to-the-vfs_streams_xa.patch and enabling STREAMS_XATTR option enabled Time Machine, and standard shares work. The only issue I had was the macOS VM kernel panicing. I don't believe this is related? Anyone able to test this with real macOS hardware? What is broken about STREAMS_XATTR option? It seems to work?
(In reply to Derek Schrock from comment #54) Heh, thanks for noticing it! I had it fixed in the Git, but, apparently, forgot to update the patch.
Would there be any harm with enabling STREAMS_XATTR by default and marking it experimental instead of broken? Enabling it just builds the module? As long as the conf isn't using it that option should cause any issues?
(In reply to Derek Schrock from comment #59) Yeh, this one I missed completely! I was made this way as module didn't work at all out of the box, but thanks to the patch, provided by Andrew Walker that is(at least for 13.1+) is fixed. So I'm removing this option again and related changes. Also, vfs_freebsd compiles now, but need to be tested, which is a bit hard with the absence of UFS2 disks around.
I can confirm with real macOS hardware TimeMachine works. If there anything interesting that can be tested for vfs_freebsd? Just UFS ACLs?
(In reply to Timur I. Bakeyev from comment #60) do you know what tests exactly need to be done? I'd love to see this up to speed and don't mind creating some jails/vms/whatever to help with he testing if I can.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=2daf87ac19838c9a36f56fb51b0678d193921771 commit 2daf87ac19838c9a36f56fb51b0678d193921771 Author: Timur I. Bakeyev <timur@FreeBSD.org> AuthorDate: 2022-10-16 23:06:57 +0000 Commit: Timur I. Bakeyev <timur@FreeBSD.org> CommitDate: 2022-10-16 23:23:12 +0000 net/samba416: New port for Samba 4.16 This is an initial attempt to add Samba to the FreeBSD after major rewrite of the VFS code in the upstream. Most of the port development is now carried in: https://gitlab.com/samba-freebsd Due to the way how new Samba VFS code is written there is a constrain that Samba 4.14+ can run only on FreeBSD 13.1+, as it requires support of the `nodup` option for the `fdesc` file system, as well as it's presence in the system in general. https://gitlab.com/samba-freebsd/-/wikis/The-New-VFS I'd like to thank CyberSecure Pty Ltd. company for their supoort of the port development and Andrew Walker from iXsystems Inc. for the patches he created and made available for the Samba4 on TrueNAS. PR: 263874 net/Makefile | 1 + net/samba416/Makefile (new) | 700 + net/samba416/distinfo (new) | 3 + ...ify-modules-build-and-config-genera.patch (new) | 292 + ...-script-to-run-under-FreeBSD-with-i.patch (new) | 35 + ...prototype-warnings-in-kadm5-admin.h.patch (new) | 32 + ...-has-different-semantics-than-on-Li.patch (new) | 38 + ...jemalloc.h-if-ENABLE_JEMALLOC-is-se.patch (new) | 26 + ...ss_-modules-into-PAMMODULESDIR-path.patch (new) | 32 + ...s-a-default-backlog-size-for-the-li.patch (new) | 105 + ...around-usage-of-Linux-specific-m-fl.patch (new) | 111 + ...nfig-checks-fail-if-the-warning-is-.patch (new) | 39 + ...kgconfigdir-to-specify-alternative-.patch (new) | 54 + ...by-port-location-of-the-XML-catalog.patch (new) | 28 + ...raries-according-to-the-FreeBSD-spe.patch (new) | 29 + ...sg-parameter-to-CHECK_LIB-so-it-can.patch (new) | 70 + ...able-CTDB-tests-failing-on-FreeBSD-.patch (new) | 77 + ...-class-to-trck-down-DB-locking-code.patch (new) | 132 + ...ttribute_compare-a-stable-comparisi.patch (new) | 29 + ...en-available-to-generate-random-tal.patch (new) | 49 + ...-option-that-allows-to-choose-alter.patch (new) | 65 + ...0b920e60e14846987ae1d2d7dca4-Mon-Se.patch (new) | 544 + ...n-r336017-and-r342928-wrongfuly-ret.patch (new) | 35 + ...ings-in-the-nfs_quota-debug-message.patch (new) | 36 + ...dling-code-and-add-FreeBSD-support..patch (new) | 340 + ...-test-function-into-vfstest-to-test.patch (new) | 121 + ...-provisioning-code-by-iXsystems-Inc.patch (new) | 367 + ...4018ebee302aae8246bf29f60309-Mon-Se.patch (new) | 101 + ...bility-option-to-the-vfs_streams_xa.patch (new) | 336 + ...s_freebsd-that-implements-FreeBSD-s.patch (new) | 932 ++ ...-system-add-FreeBSD-proc_fd_pattern.patch (new) | 149 + ...fsacl-fix-get-set-ACL-on-FreeBSD-13.patch (new) | 105 + ...c-Add-support-for-MIT-Kerberos-1.20.patch (new) | 947 ++ net/samba416/files/README.FreeBSD.in (new) | 94 + net/samba416/files/man/ctdb-script.options.5 (new) | 558 + net/samba416/files/man/ctdb-statistics.7 (new) | 550 + net/samba416/files/man/ctdb-tunables.7 (new) | 406 + net/samba416/files/man/ctdb.1 (new) | 1526 ++ net/samba416/files/man/ctdb.7 (new) | 783 ++ net/samba416/files/man/ctdb.conf.5 (new) | 359 + net/samba416/files/man/ctdb.sysconfig.5 (new) | 139 + net/samba416/files/man/ctdb_diagnostics.1 (new) | 79 + net/samba416/files/man/ctdbd.1 (new) | 83 + net/samba416/files/man/ctdbd_wrapper.1 (new) | 63 + net/samba416/files/man/dbwrap_tool.1 (new) | 329 + net/samba416/files/man/gentest.1 (new) | 133 + net/samba416/files/man/ldb.3 (new) | 427 + net/samba416/files/man/ldbadd.1 (new) | 78 + net/samba416/files/man/ldbdel.1 (new) | 80 + net/samba416/files/man/ldbedit.1 (new) | 111 + net/samba416/files/man/ldbmodify.1 (new) | 73 + net/samba416/files/man/ldbrename.1 (new) | 81 + net/samba416/files/man/ldbsearch.1 (new) | 91 + net/samba416/files/man/libsmbclient.7 (new) | 94 + net/samba416/files/man/lmhosts.5 (new) | 123 + net/samba416/files/man/locktest.1 (new) | 137 + net/samba416/files/man/log2pcap.1 (new) | 124 + net/samba416/files/man/ltdbtool.1 (new) | 256 + net/samba416/files/man/masktest.1 (new) | 113 + net/samba416/files/man/mdfind.1 (new) | 166 + net/samba416/files/man/mdsearch.1 (new) | 357 + net/samba416/files/man/mvxattr.1 (new) | 84 + net/samba416/files/man/ndrdump.1 (new) | 84 + net/samba416/files/man/nmblookup.1 (new) | 341 + net/samba416/files/man/nmblookup4.1 (new) | 157 + net/samba416/files/man/ntlm_auth.1 (new) | 458 + net/samba416/files/man/ntlm_auth4.1 (new) | 233 + net/samba416/files/man/oLschema2ldif.1 (new) | 74 + net/samba416/files/man/onnode.1 (new) | 218 + net/samba416/files/man/pam_winbind.conf.5 (new) | 161 + net/samba416/files/man/ping_pong.1 (new) | 122 + net/samba416/files/man/profiles.1 (new) | 136 + net/samba416/files/man/regdiff.1 (new) | 87 + net/samba416/files/man/regpatch.1 (new) | 81 + net/samba416/files/man/regshell.1 (new) | 177 + net/samba416/files/man/regtree.1 (new) | 89 + net/samba416/files/man/rpcclient.1 (new) | 1961 +++ net/samba416/files/man/samba-gpupdate.8 (new) | 122 + net/samba416/files/man/samba.7 (new) | 254 + net/samba416/files/man/sharesec.1 (new) | 364 + net/samba416/files/man/smb.conf.5 (new) | 13994 +++++++++++++++++++ net/samba416/files/man/smbcacls.1 (new) | 1044 ++ net/samba416/files/man/smbclient.1 (new) | 1253 ++ net/samba416/files/man/smbcontrol.1 (new) | 343 + net/samba416/files/man/smbcquotas.1 (new) | 440 + net/samba416/files/man/smbget.1 (new) | 197 + net/samba416/files/man/smbgetrc.5 (new) | 100 + net/samba416/files/man/smbpasswd.5 (new) | 175 + net/samba416/files/man/smbstatus.1 (new) | 186 + net/samba416/files/man/smbtar.1 (new) | 163 + net/samba416/files/man/smbtorture.1 (new) | 362 + net/samba416/files/man/smbtree.1 (new) | 252 + net/samba416/files/man/talloc.3 (new) | 683 + net/samba416/files/man/tdbbackup.8 (new) | 129 + net/samba416/files/man/tdbdump.8 (new) | 72 + net/samba416/files/man/tdbrestore.8 (new) | 54 + net/samba416/files/man/tdbtool.8 (new) | 170 + net/samba416/files/man/testparm.1 (new) | 194 + net/samba416/files/man/traffic_learner.7 (new) | 128 + net/samba416/files/man/traffic_replay.7 (new) | 380 + net/samba416/files/man/vfs_freebsd.8 (new) | 204 + net/samba416/files/man/wbinfo.1 (new) | 490 + .../files/patch-examples_pdb_wscript__build (new) | 11 + net/samba416/files/patch-lib_ldb_wscript (new) | 61 + net/samba416/files/patch-lib_talloc_wscript (new) | 10 + net/samba416/files/patch-lib_tdb_wscript (new) | 27 + .../files/patch-lib_util_wscript__build (new) | 11 + net/samba416/files/patch-source3_lib_util.c (new) | 14 + .../files/patch-source3_librpc_crypto_gse.c (new) | 16 + ...source3_modules_vfs__virusfilter__utils.c (new) | 36 + ...tch-source3_registry_tests_test__regfio.c (new) | 10 + .../patch-source3_winbindd_wscript__build (new) | 11 + .../files/patch-source3_wscript__build (new) | 44 + net/samba416/files/pkg-message.in (new) | 30 + net/samba416/files/samba_server.in (new) | 251 + net/samba416/pkg-descr (new) | 6 + net/samba416/pkg-plist (new) | 451 + net/samba416/pkg-plist.ad_dc (new) | 183 + net/samba416/pkg-plist.cluster (new) | 78 + net/samba416/pkg-plist.python (new) | 427 + 120 files changed, 41266 insertions(+)
Timur, there are a busload of custom patches. Do you see a change to bring them upstream? Carrying them on is a huge pain, I know that by myself for other ports where I strive for upstream fixes long-term.
FTR: For those who want to build this with Python 3.7 will fail with devel/tevent: Bug 267148
Hi, I gave the net/samba416 port a shot, and there are some issues with getting it to package up properly based on my 'make config', and then, I ran into issues when trying to connect to a share. First, for compiling as a package using 'make package', here is my 'make config': > _OPTIONS_READ=samba416-4.16.5 > _FILE_COMPLETE_OPTIONS_LIST=ADS AD_DC CLUSTER CUPS DOCS FAM GPGME LDAP MANDOC PROFILE PYTHON3 QUOTAS SPOTLIGHT SYSLOG UTMP GSSAPI_BUILTIN GSSAPI_MIT ZEROCONF_NONE AVAHI MDNSRESPONDER FRUIT GLUSTERFS > OPTIONS_FILE_UNSET+=ADS > OPTIONS_FILE_UNSET+=AD_DC > OPTIONS_FILE_UNSET+=CLUSTER > OPTIONS_FILE_UNSET+=CUPS > OPTIONS_FILE_SET+=DOCS > OPTIONS_FILE_UNSET+=FAM > OPTIONS_FILE_UNSET+=GPGME > OPTIONS_FILE_UNSET+=LDAP > OPTIONS_FILE_UNSET+=MANDOC > OPTIONS_FILE_UNSET+=PROFILE > OPTIONS_FILE_SET+=PYTHON3 > OPTIONS_FILE_UNSET+=QUOTAS > OPTIONS_FILE_UNSET+=SPOTLIGHT > OPTIONS_FILE_SET+=SYSLOG > OPTIONS_FILE_SET+=UTMP > OPTIONS_FILE_SET+=GSSAPI_BUILTIN > OPTIONS_FILE_UNSET+=GSSAPI_MIT > OPTIONS_FILE_SET+=ZEROCONF_NONE > OPTIONS_FILE_UNSET+=AVAHI > OPTIONS_FILE_UNSET+=MDNSRESPONDER > OPTIONS_FILE_UNSET+=FRUIT > OPTIONS_FILE_UNSET+=GLUSTERFS Using that build configuration, it seems the plist files get a few things wrong and include one binary that isn't needed and exclude a number of libraries that are needed for smbd to run. What I didn't need (only relevant for an AD DC, as I am running a standalone instance): > bin/samba-tool Libraries that were not part of any of the pkg-plist* files in their entirety that were needed to start the smbd service: > /usr/local/lib/samba4/private/libasn1-samba4.so > /usr/local/lib/samba4/private/libroken-samba4.so > /usr/local/lib/samba4/private/libcom-err-samba4.so > /usr/local/lib/samba4/private/libgssapi-samba4.so > /usr/local/lib/samba4/private/libhcrypto-samba4.so > /usr/local/lib/samba4/private/libheimbase-samba4.so > /usr/local/lib/samba4/private/libhx509-samba4.so > /usr/local/lib/samba4/private/libkrb5-samba4.so > /usr/local/lib/samba4/private/libwind-samba4.so Once I fixed this manually (editing work/.PLIST.mktmp, removing work/.package_done.samba416._usr_local, and then re-running 'make package'), I finally got a working installation. Tangential question: Is there a reason why FreeBSD's ports system needs these plist files instead of just packaging up whatever the target's 'install' command installs into the staging area? I come from a Gentoo Linux background, and Portage, which was inspired by Ports, is generally capable of working out what to package up from what the build system installs to the staging area (not always, but enough so that they don't need to maintain anything similar to the plist files). --- In any event, that leads to the next issue: actually connecting. My smb4.conf file needed no modifications to work with the new version (just two deprecation warnings from testparm), but trying to connect to a share on my home network hosted by this FreeBSD server that worked under 4.13.17, using the 'nobody' user, the connection fails. Turning up the logging level, it looks like it may be a filesystem access issue. My only defined share "nas" is on a ZFS dataset, and under 4.13.17, this is the point where it succeeds and where 4.16.5 fails: 4.13.17: > [2022/10/17 11:45:32.428457, 2] ../../source3/smbd/service.c:852(make_connection_snum) > desktop (ipv4:<ipv4_address>:55201) connect to service nas initially as user nobody (uid=65534, gid=65534) (pid 5350) > > [2022/10/17 11:45:32.429516, 3] ../../source3/smbd/smb2_server.c:3863(smbd_smb2_request_error_ex) > smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_OBJECT_NAME_NOT_FOUND] || at ../../source3/smbd/smb2_create.c:334 > [2022/10/17 11:45:32.432182, 3] ../../source3/smbd/dir.c:910(smbd_dirptr_get_entry) > smbd_dirptr_get_entry mask=[*] found . fname=. (.) > [2022/10/17 11:45:32.432282, 3] ../../source3/smbd/dir.c:910(smbd_dirptr_get_entry) > smbd_dirptr_get_entry mask=[*] found .. fname=.. (..) > (((more files listed))) 4.16.5: > [2022/10/17 11:39:21.683235, 2] ../../source3/smbd/service.c:854(make_connection_snum) > desktop (ipv4:<ipv4_address>:55169) connect to service nas initially as user nobody (uid=65534, gid=65534) (pid 88432) > > [2022/10/17 11:39:21.684411, 3] ../../source3/smbd/smb2_server.c:3956(smbd_smb2_request_error_ex) > smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_OBJECT_NAME_NOT_FOUND] || at ../../source3/smbd/smb2_create.c:338 > [2022/10/17 11:39:21.685017, 3] ../../source3/smbd/smb2_server.c:3956(smbd_smb2_request_error_ex) > smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_OBJECT_NAME_NOT_FOUND] || at ../../source3/smbd/smb2_create.c:338 > [2022/10/17 11:39:27.065344, 3] ../../source3/smbd/smb2_server.c:3956(smbd_smb2_request_error_ex) > smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_OBJECT_NAME_NOT_FOUND] || at ../../source3/smbd/smb2_create.c:338 > (((connection to share fails at this point))) I am unsure what is failing at this point, though, or whether it's related to ZFS or not. It seems the first access in both cases fails (returning NT_STATUS_OBJECT_NAME_NOT_FOUND), but 4.13.17 succeeds at this point and starts to return file entries (I included the '.' and '..' ones to show this), whereas 4.16.5 returns two more NT_STATUS_OBJECT_NAME_NOT_FOUND errors and then aborts (and on my desktop running Windows, I get an error popup). I changed nothing on the filesystem side during this test, and was able to easily switch back to 4.13.17 and everything simply started working again. So I suspect it's a yet-unresolved issue with the VFS stuff mentioned earlier that changed in upstream Samba. In any event, hopefully that helps with debugging...
(In reply to Joshua Kinard from comment #66) As for plist issue, bug #267141 may helps you.
(In reply to Michael Osipov from comment #64) Well, Michael, it's not that I'm against putting those patches to upstream... Over 20+ years I'm periodically trying to do so and sometimes even succeed. But overall process for each patch takes a lot of time and effort, so eventually I give up... If you feel force(tm) to chase Samba team I'm all to introduce you to the patches and what they do and can help you with brushing them, if any. But I'm quite skeptical about the results :(
(In reply to Timur I. Bakeyev from comment #68) I perfectly know what you mean. I went through this with Python on HP-UX and gave up after a few PRs. Quite sad. Although, I cannot tell how receptive the Samba team is compared to the huge Python one. Let's make this work first and reconsider end of year since this is the only current working version and should not fail/disappear on FreeBSD in the near future. Thanks!
<https://cgit.freebsd.org/ports/tree/net/samba416/Makefile#n10> > WWW= https://www.samba.org/ (In reply to commit-hook from comment #63) > Most of the port development is now carried in: > > https://gitlab.com/samba-freebsd For what it's worth: with a port such as this, I'd find the GitLab page more _directly_ useful (as the WWW point of reference) than the samba.org page. <https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-www> – WWW can be "a directory or resource in the source code repository". Thanks
Close this bug report as Samba 4.16 is added to ports tree. If there is any issue about Smaba or net/samba416 port, please submit it as new bug report.
(In reply to Graham Perrin from comment #70) Ok, point taken :)
Would it be preferred that freebsd-specific samba bugs/issues are still primarily tracked here on bugs.freebsd.org? Or should one consider using https://gitlab.com/groups/samba-freebsd/-/issues? I could see merits to both, so I thought I'd ask here. I suspect bugs.freebsd.org is probably still best, but given that gitlab has the option people will likely start using the issue tracker there. Two places for bug tracking is probably worse than just one.
I try to get FreeBSD14 stable running with both - GNOME - SAMBA However that seems to be impossible. GNOME and SAMBA416 seems to be conflicting. Where I need SAMBA416 since SAMBA413 is simply not working :( pkg install samba416-4.16.6 Message from samba416-4.16.6 [1/4] Deinstalling gnome-shell-42.4_1... [1/4] Deleting files for gnome-shell-42.4_1: 100% [2/4] Deinstalling gnome-control-center-43.0... [2/4] Deleting files for gnome-control-center-43.0: 100% [3/4] Deinstalling samba413-4.13.17_4... [3/4] Deleting files for samba413-4.13.17_4: 100% [4/4] Installing samba416-4.16.6... [4/4] Extracting samba416-4.16.6: 100% And then I have a fatal GNOME problem, and I have to install GNOME shell Nov 6 12:29:20 SENIOR pkg[1897]: samba416-4.16.6 deinstalled Nov 6 12:29:21 SENIOR pkg[1897]: samba413-4.13.17_4 installed Nov 6 12:29:21 SENIOR pkg[1897]: gnome-control-center-43.0 installed Nov 6 12:29:21 SENIOR pkg[1897]: gnome-shell-42.4_1 installed So, that is a squeeze which urgently need repair IMHO
(In reply to Louis from comment #74) Dont hijack issues, create new ones.