This page tries to summarize the current status of Samba on FreeBSD operating system.
There is a Samba page on FreeBSD's wiki, but it was last updated nearly fifteen years ago.
Recently multiple threads appeared on FreeBSD's official mailing lists (e.g. this and this), but there were more questions than answers; OTOH, there's been a lot of activities going on in several Bugzilla reports.
Warning: these informations are what I found with my researches on the web and my own tests; I cannot guarantee they are 100% exact or complete and I take no responsibility. You are welcome to mail me corrections, additions, suggestions, etc...
The new VFS seems to require the nodup option of fdescfs. This means FreeBSD versions before 13.x are out of luck and the port has currently been marked IGNOREd for <13.1.
Support for legacy OS versions (12.4) might be investigated in the future.
If running on 12.4 is required now, with specific limitations, one might try to remove the IGNORE line and test: 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. YMMV.
Whenever in Samba's documentation you read "/usr/local/samba", keep in mind that on FreeBSD, the databases are in /var/db/samba4.
The Samba ports requires a lot of libraries to build: for a few of them, a choice exist to either use a bundled version or a dependent port.
By default ldb is bundled, while cmocka, talloc, tevent and tdb are not.
Not bundling tdb might be the cause of "samba-tool offine backup" getting stuck (see this thread). TODO: check this!
Samba makes use of filesystem ACLs (which, unfortunately, are not fully standardized between different OSes and FSes):
a fileserver or NT DC should use POSIX ACLs or Windows ACLs (which in turn requires use of xattr);
it is however possible to only use standard UNIX permissions for shares and/or use some options (e.g. [in]valid users, force create mode, etc...) in /usr/local/etc/smb4.conf to manage monolithic access to shares;
Samba is quite Linux-centric on ACL/xattr handling, but ACLs and xattr in FreeBSD are different from Linux. Also, running Samba in a jail further complicates things.
While a full solution is still under discussion, there seems to be, at the moment, a few alternatives:
If using ZFS, it might be useful to take periodical snapshots (with py-zfs-autobackup or similar tool) and let users access them as "previous versions".
A tentative was made to create a libzfs based general solution, but seems far from being usable.
Meanwhile the standard vfs_shadow_copy2 module can do, provided it is configured properly (but see this bug).
Also read on if you are running Samba in a jail.
Running Samba in a jail is a controversial practice: while it has obvious advantages (e.g. running an AD DC and a fileserver on the same machine), some people think it is a bad idea; others are instead doing this and report it as working. Upstream will usually wash their hands of any trouble if Samba does not work in a jail.
One peculiarity of jails is the inability to access the SYSTEM extended attributes namespace:
Samba 4.16's RC script also wants to mount its own private fdescfs filesystem: in order to allow for this in a jail, you need allow.mount.fdescfs=true, which in turns needs enforce_statfs<2.
Jail privileges are clearly insufficient, if, when starting Samba, you see:
warn "samba_server: cannot fdescfs mount to /var/run/samba4/fd"
Due to the script not working properly, you could also see:
mount: none: Operation not permitted
If using EZJail, you should edit /usr/local/etc/ezjail/{jail_name}, with the following line:
export jail_{jail_name}_parameters="allow.mount.fdescfs=true enforce_statfs=1"
If using ZFS and you want shadow copies:
Also notice they can't possibly work for directories mounted from outside the jail (e.g. with nullfs).
It can happen that some Samba daemon crashes, but is unable to produce a core; in the log something the following will show up:
unable to change to %N.core
refusing to dump core
Setting the following should solve:
sysctl kern.corefile=/somepath/%N_%P.core
sysctl kern.sugid_coredump=1
Notice that, in order to be able to get useful dumps, Samba needs to be compiled WITH_DEBUG.
This list tries to address some of the current problems users are like to encounter and provide links to relevant informations, possibly providing a solution or workaround.
By no means this list is meant to be exhaustive.
Upgrading from 4.8 to 4.10 should be attempted by following Samba's standard procedure. Non-FreeBSD specific notes are mostly out of scope here.
Things to pay attention to:
since Samba 4.9, the new default for ea support in smb4.conf has been changed to yes.
smb.conf(5) notes however that "the SMB protocol allows setting attributes whose value is 64K bytes long, and that on NTFS, the maximum storage space for extended attributes per file is 64K. On most UNIX systems (Solaris and ZFS file system being the exception), the limits are much lower - typically 4K. Worse, the same 4K space is often used to store system metadata such as POSIX ACLs, or Samba's NT ACLs. Giving clients access to this tight space via extended attribute support could consume all of it by unsuspecting client applications, which would prevent changing system metadata due to lack of space.
Take care if you're using UFS.
Warning: information in this chapter was collected a long time ago and many things might have changed. It might not be true, fresh, or relevant anymore.
In the first place, provisioning seems to fail unless you specify additional options.
Adding --option="vfs objects=freebsd" seems to be enough to provision in a non jailed UFS2-with-ACLs situation.
Similarly --option="vfs objects=zfsacl" lets provisioning work on ZFS (base or jail).
Given that, I've had mixed results, as updates to the ports seem to have intermittently broken and fixed it (see this bug).
Warning: information in this chapter was collected a long time ago and many things might have changed. It might not be true, fresh, or relevant anymore.
I've managed to Classic upgrades succesfully on ZFS with --option="vfs objects=zfsacl".
Given that, I've had mixed results, as updates to the ports seem to have intermittently broken and fixed it (see this bug).
If a jailed AD DC instance does not start, the cause might be to the nbt service.
See this bug for full info and workaround.
I've seen this on several systems running Samba 4.16 after the upgrade from FreeBSD 13.1 to 13.2 (with absolutely no changes in the configurations/options/etc...).
While the underlying cause is still unknown to me, the following is a quick fix:
find {share} -exec rmextattr user DOSATTRIB "{}" ";"
Take backups before doing this, as I take no responsibility for any side-effect.
Page last updated on 2023/6/3.