Re: Deprecating smbfs(5) and removing it before FreeBSD 14

From: Rick Macklem <>
Date: Sun, 9 Jan 2022 14:46:52 +0000
Well, I took a look at the Apple code and I'm afraid I
think porting it into FreeBSD is too big a job for me.

I was hoping the code would have a layer that could
be used as a "block box" for the VOP calls, but that
does not seem to be the case.
There is also a *lot* of code in it.

I am going to look at the OpenSolaris code, to see if
I think it will be an easier port.


From: Miroslav Lachman <>
Sent: Monday, November 1, 2021 5:47 PM
To: Rick Macklem;; freebsd-stable
Cc: Yuri
Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to

On 01/11/2021 16:55, Rick Macklem wrote:
> Miroslav Lachman wrote:
> [good stuff snipped]
>> Apple sources can be found there
>> with all the history from SMBv1
>> to SMBv3. The files have original copyright header from 2001 Boris Popov
>> (same as FreeBSD) but otherwise it is very different code due to
>> different kernel interfaces and so on.
>> With Apple and Illumos sources it is possible to have smbfs in FreeBSD
>> upgraded to v2 or v3 but very skilled programmer is needed for this
>> work. And for the past years there is none interested in this work.
> Although I agree that it would be a non-trivial exercise, a lot of the Apple
> differences are in the "smoke and mirrors" category.
> Around OSX 10.4, they changed their VFS/VOP to typedefs and accessor
> functions. For example:
>         "struct vnode *vp" became "vnode_t vp"
> and "vp->v_type" became "vnode_type(vp)"
> Ten years ago, the actual semantics were very close to what FreeBSD used.
> If you look at sys/fs/nfs/nfskpiport.h in older sources (around FreeBSD 10),
> you'll see a bunch of macros I used to allow the Apple port to also build/run
> on FreeBSD (a couple, such as vnode_t are still left because I've never gotten
> around to doing the edit to replace them).

If I see it right even the 10 years old Apple version of smbfs has
support for SMBv2 so if this old version is closer to FreeBSD kernel /
smbfs it can be a good starting point to merge changes to our smbfs to
have SMBv2 support on FreeBSD.

> The hard part will be dealing with the actual VFS/VOP semantics changes that
> have occurred in the last 10 years.
> Did they stick APSLs on the files? (If so, I think it could still be ok, since the APSL
> is a lot like the CDDL. However, I'm not sure if the APSL has ever been blessed
> by FreeBSD as of yet?)

The old versions of smbfs has original copyright header and no other
license. Newer version has some added files with different header with
APSL license. For example

If license is a problem then I think it can live with APSL in the ports
tree as a loadable kernel module. Maybe this will be the easier for
development too?

> Don't assume anything will happen, but I *might* take a look in the winter,
> since outstanding NFS changes should be done by the end of 2021.

I really appreciate your endless work on NFS on FreeBSD. Without your
work the NFS will be lacking behind industry standards similar to what
we see with smbfs.
And if you will have some spare time to take a look on smbfs and maybe
solve the SMBv2 / SMBv3 problem you will be my hero. I am waiting for it
for many years and I know I am not alone who needs working SMB / CIFS on

> It does sound like there is some interest in this and that fuse doesn't solve
> the problem (at least for everyone).

Yes, there is an interest. It was discussed few times in the past in the
mailing lists and web but without anybody willing to
touch the code.
FUSE alternatives have so many problems with performance, stability and

Kind regards
Miroslav Lachman
Received on Sun Jan 09 2022 - 14:46:52 UTC

Original text of this message