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

From: Miroslav Lachman <>
Date: Mon, 10 Jan 2022 16:27:40 +0100
Hello Rick,
thank you for the update and your time on smbfs. I hope OpenSolaris 
version will be portable. (or mayby some older version from Apple?)
FreeBSD without possibility to mount smbfs is not an option for some 

Kind regards
Miroslav Lachman

On 09/01/2022 15:46, Rick Macklem wrote:
> 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.
> rick
> ________________________________________
> 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
> FreeBSD.
>> 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
> configuration.
> Kind regards
> Miroslav Lachman
Received on Mon Jan 10 2022 - 15:27:40 UTC

Original text of this message