Introduction

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.

There's been some activitiy going on in several Bugzilla reports.

Warning: these informations are what I found with my own 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...

Samba versions

4.16.11: available in HEAQ and 2025Q2 port trees.
Altough this version is unsupported upstream, and deprecation from the port tree has already been proposed, this is still the default version.
It is probably affected by several vulnerabilities:
4.19.9: available in the HEAD and 2025Q2 port trees.
Notice this version is already unsupported upstream.
4.20.7: available in the HEAD and 2025Q2 port trees.
This version does not work.
4.21.x: there's a discussion about porting this version, but with no results yet.

General issues

Databases location

Whenever in Samba's documentation you read "/usr/local/samba", keep in mind that on FreeBSD, the databases are in /var/db/samba4.

Bundled libraries

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 they are currently not bundled.

In a few cases, using bundled version might solve some bugs.

ACLs

Samba makes use of filesystem ACLs (which, unfortunately, are not fully standardized between different OSes and FSes):

a machine just running winbind for NSS/PAM doesn't need ACLs;
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;
an AD DC must use Windows ACLs (unless you are going to use it for authentication only and accept netlogon script, GPO, etc... will NOT work properly).

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 was discussed, none was found. There seem to be, at the moment, a few alternatives:

you can choose not to use Windows ACL (not possible for SYSVOL on an AD DC);
for UFS an experimental VFS module (vfs_freebsd) is included since 4.10; see its man page for details and be aware of what to do when starting to use it on existing installations;
for ZFS, there's a vfs_zfsalcl module. TODO: find more informations on this.

Shadow copies

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.

Jails

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:

if you are on UFS, see above: you'll need to use vfs_freebsd in compat mode;
TODO: on ZFS?

Samba'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, you'll need to add zfs.mount_snapshot=1 to the above.

Also notice they can't possibly work for directories mounted from outside the jail (e.g. with nullfs).

Missing cores

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.

Specific problems

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.

Provisioning an AD DC domain

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).

Classic upgrade

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).

AD DC in a jail not starting

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.

"Directory name is invalid" when opening files

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 2025/4/23.