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

From: Miroslav Lachman <>
Date: Mon, 1 Nov 2021 22:47:03 +0100
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 Mon Nov 01 2021 - 21:47:03 UTC

Original text of this message