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

[Miroslav Lachman]

On 16/06/2022 15:56, Rick Macklem wrote:

Miroslav Lachman <000.f...@quip.cz> wrote:

On 24/01/2022 16:13, Rick Macklem wrote:


[...]



So, I think Mark and Yuri are correct and looking at up to date
Illumos sources is the next step.
(As I mentioned, porting the Apple sources is beyond what I am
   willing to attempt.)

rick


Hello Rick,
I would like to ask you I there is some progress with porting newer
SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
possibility where to start porting?

Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date
and I agree that it should be easier than the Apple stuff to port into
FreeBSD.  I don't think it is "straightforward" as someone involved
with Illumos said, due to the big differences in VFS/locking, but...

Having said the above, I have not done much yet. I've been cleaning up
NFS stuff, although I am nearly done with that now.
I do plan on starting to work on it soon, but have no idea if/when I
will have something that might be useful for others.


I'm glad to hear that.


We have more and more problems with current state of mount_smbfs. I
would be really glad if "somebody" can do the heroic work of
implementing SMBv2 in FreeBSD.
Maybe it's time to start some fundraising for sponsoring this work?

Well, funding isn't an issue for me (I'm just a retired guy who does this
stuff as a hobby). However, if there is someone else who is capable of
doing it if they are funded, I have no problem with that.
I could either help them, or simply stick with working on NFS and leave
SMBv23 to them.

Sorry, but I cannot report real progress on this as yet, rick


No need to sorry. I really appreciate your endless work on NFS and that 
you still have kind of interest to try porting SMBv2/3.

Unfortunately I don't know anybody else trying to do this tremendous work.

Kind regards
Miroslav Lachman

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

[Rick Macklem]

Miroslav Lachman <000.f...@quip.cz> wrote:
> On 24/01/2022 16:13, Rick Macklem wrote:
>
[...]
>
> > So, I think Mark and Yuri are correct and looking at up to date
> > Illumos sources is the next step.
> > (As I mentioned, porting the Apple sources is beyond what I am
> >   willing to attempt.)
> >
> > rick
>
> Hello Rick,
> I would like to ask you I there is some progress with porting newer
> SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
> possibility where to start porting?
Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date
and I agree that it should be easier than the Apple stuff to port into
FreeBSD.  I don't think it is "straightforward" as someone involved
with Illumos said, due to the big differences in VFS/locking, but...

Having said the above, I have not done much yet. I've been cleaning up
NFS stuff, although I am nearly done with that now.
I do plan on starting to work on it soon, but have no idea if/when I
will have something that might be useful for others.

> We have more and more problems with current state of mount_smbfs. I
> would be really glad if "somebody" can do the heroic work of
> implementing SMBv2 in FreeBSD.
> Maybe it's time to start some fundraising for sponsoring this work?
Well, funding isn't an issue for me (I'm just a retired guy who does this
stuff as a hobby). However, if there is someone else who is capable of
doing it if they are funded, I have no problem with that.
I could either help them, or simply stick with working on NFS and leave
SMBv23 to them.

Sorry, but I cannot report real progress on this as yet, rick

Kind regards
Miroslav Lachman


> 
> From: owner-freebsd-curr...@freebsd.org  
> on behalf of David Chisnall 
> Sent: Monday, January 24, 2022 5:16 AM
> To: freebsd-current@freebsd.org
> 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 
> ith...@uoguelph.ca
>
>
> On 22/01/2022 23:20, Rick Macklem wrote:
>> Mark Saad  wrote:
>> [stuff snipped]
>>> So I am looking at the Apple and Solaris code, provided by rick. I am not
>>> sure if the illumos code provides SMB2 support. They based the solaris
>>> code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure
>>> predates smb2 .
>>>
>>> https://github.com/apple-oss-distributions/smb/tree/smb-217.19
>>>
>>> If I am following this correctly we need to look at Apple's smb client
>>> from OSX 10.9  which is where I start to see bits about smb2
>>>
>>> https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/netsmb
>>>
>>> This is also where this stuff starts to look less and less like FreeBSD .
>>> Let me ask some of the illumos people I know to see if there is
>>> anything they can point to.
>> Yes. Please do so. I saw the "old" calls fo things like open and the
>> new ntcreate version, so I assumed that was the newer SMB.
>> If it is not, there is no reason to port it.
>>
>> The new Apple code is a monster. 10x the lines of C and a lot of
>> weird stuff that looks Apple specific.
>>
>> It might actually be easier to write SMBv2 from the spec than port
>> the Apple stuff.
>> --> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3.
>>
>> Thanks for looking at this, rick
>
> The docs are public:
>
> https://docs.microsoft.com/en-gb/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962
>
>
> Note that the spec is 480 pages, it is not a trivial protocol to
> implement from scratch.
>
> David
>
>

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

[Miroslav Lachman]

On 24/01/2022 16:13, Rick Macklem wrote:

[...]


So, I think Mark and Yuri are correct and looking at up to date
Illumos sources is the next step.
(As I mentioned, porting the Apple sources is beyond what I am
  willing to attempt.)

rick


Hello Rick,
I would like to ask you I there is some progress with porting newer 
SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a 
possibility where to start porting?


We have more and more problems with current state of mount_smbfs. I 
would be really glad if "somebody" can do the heroic work of 
implementing SMBv2 in FreeBSD.

Maybe it's time to start some fundraising for sponsoring this work?

Kind regards
Miroslav Lachman




From: owner-freebsd-curr...@freebsd.org  on behalf 
of David Chisnall 
Sent: Monday, January 24, 2022 5:16 AM
To: freebsd-current@freebsd.org
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 ith...@uoguelph.ca


On 22/01/2022 23:20, Rick Macklem wrote:

Mark Saad  wrote:
[stuff snipped]

So I am looking at the Apple and Solaris code, provided by rick. I am not
sure if the illumos code provides SMB2 support. They based the solaris
code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure
predates smb2 .

https://github.com/apple-oss-distributions/smb/tree/smb-217.19

If I am following this correctly we need to look at Apple's smb client
from OSX 10.9  which is where I start to see bits about smb2

https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/netsmb

This is also where this stuff starts to look less and less like FreeBSD .
Let me ask some of the illumos people I know to see if there is
anything they can point to.

Yes. Please do so. I saw the "old" calls fo things like open and the
new ntcreate version, so I assumed that was the newer SMB.
If it is not, there is no reason to port it.

The new Apple code is a monster. 10x the lines of C and a lot of
weird stuff that looks Apple specific.

It might actually be easier to write SMBv2 from the spec than port
the Apple stuff.
--> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3.

Thanks for looking at this, rick


The docs are public:

https://docs.microsoft.com/en-gb/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962


Note that the spec is 480 pages, it is not a trivial protocol to
implement from scratch.

David

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

[Rick Macklem]

Yea, I've been looking at that spec. a little bit.
I'll admit that encryption related stuff isn't my favourite work
and that appears to be a significant part of the changes to SMB2/3.

I did find some entries in Illumos gate related to integration
of SMBv2.1 about 3-4years ago. It was not completely obvious
whether the entries referred to client or server and it noted a
work effort of 500hrs.

So, I think Mark and Yuri are correct and looking at up to date
Illumos sources is the next step.
(As I mentioned, porting the Apple sources is beyond what I am
 willing to attempt.)

rick


From: owner-freebsd-curr...@freebsd.org  on 
behalf of David Chisnall 
Sent: Monday, January 24, 2022 5:16 AM
To: freebsd-current@freebsd.org
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 ith...@uoguelph.ca


On 22/01/2022 23:20, Rick Macklem wrote:
> Mark Saad  wrote:
> [stuff snipped]
>> So I am looking at the Apple and Solaris code, provided by rick. I am not
>> sure if the illumos code provides SMB2 support. They based the solaris
>> code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure
>> predates smb2 .
>>
>> https://github.com/apple-oss-distributions/smb/tree/smb-217.19
>>
>> If I am following this correctly we need to look at Apple's smb client
>> from OSX 10.9  which is where I start to see bits about smb2
>>
>> https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/netsmb
>>
>> This is also where this stuff starts to look less and less like FreeBSD .
>> Let me ask some of the illumos people I know to see if there is
>> anything they can point to.
> Yes. Please do so. I saw the "old" calls fo things like open and the
> new ntcreate version, so I assumed that was the newer SMB.
> If it is not, there is no reason to port it.
>
> The new Apple code is a monster. 10x the lines of C and a lot of
> weird stuff that looks Apple specific.
>
> It might actually be easier to write SMBv2 from the spec than port
> the Apple stuff.
> --> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3.
>
> Thanks for looking at this, rick

The docs are public:

https://docs.microsoft.com/en-gb/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962


Note that the spec is 480 pages, it is not a trivial protocol to
implement from scratch.

David

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

[David Chisnall]

On 22/01/2022 23:20, Rick Macklem wrote:

Mark Saad  wrote:
[stuff snipped]

So I am looking at the Apple and Solaris code, provided by rick. I am not
sure if the illumos code provides SMB2 support. They based the solaris
code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure
predates smb2 .

https://github.com/apple-oss-distributions/smb/tree/smb-217.19

If I am following this correctly we need to look at Apple's smb client
from OSX 10.9  which is where I start to see bits about smb2

https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/netsmb

This is also where this stuff starts to look less and less like FreeBSD .
Let me ask some of the illumos people I know to see if there is
anything they can point to.

Yes. Please do so. I saw the "old" calls fo things like open and the
new ntcreate version, so I assumed that was the newer SMB.
If it is not, there is no reason to port it.

The new Apple code is a monster. 10x the lines of C and a lot of
weird stuff that looks Apple specific.

It might actually be easier to write SMBv2 from the spec than port
the Apple stuff.
--> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3.

Thanks for looking at this, rick


The docs are public:

https://docs.microsoft.com/en-gb/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962


Note that the spec is 480 pages, it is not a trivial protocol to 
implement from scratch.


David

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

[Rick Macklem]

Mark Saad  wrote:
[stuff snipped]
> So I am looking at the Apple and Solaris code, provided by rick. I am not
> sure if the illumos code provides SMB2 support. They based the solaris
> code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure
> predates smb2 .
>
> https://github.com/apple-oss-distributions/smb/tree/smb-217.19
>
> If I am following this correctly we need to look at Apple's smb client
> from OSX 10.9  which is where I start to see bits about smb2
>
> https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/netsmb
>
> This is also where this stuff starts to look less and less like FreeBSD .
> Let me ask some of the illumos people I know to see if there is
> anything they can point to.
Yes. Please do so. I saw the "old" calls fo things like open and the
new ntcreate version, so I assumed that was the newer SMB.
If it is not, there is no reason to port it.

The new Apple code is a monster. 10x the lines of C and a lot of
weird stuff that looks Apple specific.

It might actually be easier to write SMBv2 from the spec than port
the Apple stuff.
--> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3.

Thanks for looking at this, rick



--
mark saad | nones...@longcount.org

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

[Rick Macklem]

Yuri  wrote:
> Rick Macklem wrote:
> > I have downloaded the final version of the opensolaris
> > smbfs and it looks much more reasonable to port to
> > FreeBSD.
>
> What do you mean by "final version of the opensolaris smbfs", the one
> from 2010?  Please note that illumos (actively maintained fork of
> opensolaris) has a much more up to date one.
I'm not surprised that illumos will have updates.
I don't think it will affect the exercise at this time, since the current work
is to figure out what pieces of the opensolaris code needs to be pulled
into the current smbfs to make the newer version work.
Solaris uses a very different VFS/VOP locking model, so a direct port
of the opensolaris code would be more work than I will be attempting.

rick

> I will be starting to work on this (and maybe Mark Saad will be
> able to help).
>
> I have no idea when I'll have code that can be tested by others.
>
> rick
>
> 
> From: Miroslav Lachman <000.f...@quip.cz>
> Sent: Monday, January 10, 2022 10:27 AM
> To: Rick Macklem; freebsd-current@freebsd.org; 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 
> ith...@uoguelph.ca
>
>
> 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
> projects.
>
> 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 <000.f...@quip.cz>
>> Sent: Monday, November 1, 2021 5:47 PM
>> To: Rick Macklem; freebsd-current@freebsd.org; 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 
>> ith...@uoguelph.ca
>>
>>
>> On 01/11/2021 16:55, Rick Macklem wrote:
>>> Miroslav Lachman wrote:
>>> [good stuff snipped]
>>>> Apple sources can be found there
>>>> https://opensource.apple.com/source/smb/ 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.
>>
>&g

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

[Rick Macklem]

I have downloaded the final version of the opensolaris
smbfs and it looks much more reasonable to port to
FreeBSD.

I will be starting to work on this (and maybe Mark Saad will be
able to help).

I have no idea when I'll have code that can be tested by others.

rick


From: Miroslav Lachman <000.f...@quip.cz>
Sent: Monday, January 10, 2022 10:27 AM
To: Rick Macklem; freebsd-current@freebsd.org; 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 ith...@uoguelph.ca


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

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 <000.f...@quip.cz>
> Sent: Monday, November 1, 2021 5:47 PM
> To: Rick Macklem; freebsd-current@freebsd.org; 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 
> ith...@uoguelph.ca
>
>
> On 01/11/2021 16:55, Rick Macklem wrote:
>> Miroslav Lachman wrote:
>> [good stuff snipped]
>>> Apple sources can be found there
>>> https://opensource.apple.com/source/smb/ 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
> https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_subr_2.h.auto.html
>
> 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 yo

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

[Miroslav Lachman]

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


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 <000.f...@quip.cz>
Sent: Monday, November 1, 2021 5:47 PM
To: Rick Macklem; freebsd-current@freebsd.org; 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 ith...@uoguelph.ca


On 01/11/2021 16:55, Rick Macklem wrote:

Miroslav Lachman wrote:
[good stuff snipped]

Apple sources can be found there
https://opensource.apple.com/source/smb/ 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
https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_subr_2.h.auto.html

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 forums.freebsd.org but without anybody willing to
touch the code.
FUSE alternatives have so many problems with performance, stability and
configuration.
https://forums.freebsd.org/threads/getting-smbnetfs-to-work.78413/

Kind regards
Miroslav Lachman

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

[Rick Macklem]

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 <000.f...@quip.cz>
Sent: Monday, November 1, 2021 5:47 PM
To: Rick Macklem; freebsd-current@freebsd.org; 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 ith...@uoguelph.ca


On 01/11/2021 16:55, Rick Macklem wrote:
> Miroslav Lachman wrote:
> [good stuff snipped]
>> Apple sources can be found there
>> https://opensource.apple.com/source/smb/ 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
https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_subr_2.h.auto.html

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 forums.freebsd.org but without anybody willing to
touch the code.
FUSE alternatives have so many problems with performance, stability and
configuration.
https://forums.freebsd.org/threads/getting-smbnetfs-to-work.78413/

Kind regards
Miroslav Lachman

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

[Miroslav Lachman]

On 01/11/2021 16:55, Rick Macklem wrote:

Miroslav Lachman wrote:
[good stuff snipped]

Apple sources can be found there
https://opensource.apple.com/source/smb/ 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 
https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_subr_2.h.auto.html


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 forums.freebsd.org but without anybody willing to 
touch the code.
FUSE alternatives have so many problems with performance, stability and 
configuration.

https://forums.freebsd.org/threads/getting-smbnetfs-to-work.78413/

Kind regards
Miroslav Lachman

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

[Warner Losh]

On Mon, Nov 1, 2021 at 12:29 PM Ed Maste  wrote:

> On Mon, 1 Nov 2021 at 11:56, Rick Macklem  wrote:
> >
> > 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?)
>
> I had a quick look at the Illumos kernel files and it appears each
> file is licensed under only one of 4-clause BSD, APSL, or CDDL,
> depending on where it originated.
>
> Files from Boris Popov's original FreeBSD implementation have the
> 4-clause BSD license, followed by something like:
> /*
>  * Copyright (c) 2008, 2010, Oracle and/or its affiliates. All rights
> reserved.
>  * Portions Copyright (C) 2001 - 2013 Apple Inc. All rights reserved.
>  * Copyright 2018 Nexenta Systems, Inc.  All rights reserved.
>  */
>
> There are 28 BSD-licensed kernel files, 5 APSL, and 13 CDDL. I think
> that having an smbfs kernel module in the tree using a combination of
> those licenses is fine. (This isn't on behalf of core@ and of course
> due diligence needs to be done, but from a high level it seems
> reasonable.)
>

Yea, I took a quick look and came to a similar conclusion: this code base
is likely fine for inclusion from a license perspective, but would take some
doing to get it working on FreeBSD robustly for all the reasons that Rick
delved into far better than I can...

Warner

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

[Ed Maste]

On Mon, 1 Nov 2021 at 11:56, Rick Macklem  wrote:
>
> 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?)

I had a quick look at the Illumos kernel files and it appears each
file is licensed under only one of 4-clause BSD, APSL, or CDDL,
depending on where it originated.

Files from Boris Popov's original FreeBSD implementation have the
4-clause BSD license, followed by something like:
/*
 * Copyright (c) 2008, 2010, Oracle and/or its affiliates. All rights reserved.
 * Portions Copyright (C) 2001 - 2013 Apple Inc. All rights reserved.
 * Copyright 2018 Nexenta Systems, Inc.  All rights reserved.
 */

There are 28 BSD-licensed kernel files, 5 APSL, and 13 CDDL. I think
that having an smbfs kernel module in the tree using a combination of
those licenses is fine. (This isn't on behalf of core@ and of course
due diligence needs to be done, but from a high level it seems
reasonable.)

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

[Rick Macklem]

Miroslav Lachman wrote:
[good stuff snipped]
> Apple sources can be found there
> https://opensource.apple.com/source/smb/ 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).

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

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.

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

rick

Miroslav Lachman

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

[Miroslav Lachman]

On 01/11/2021 09:36, Yuri wrote:

Ed Maste wrote:

The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and
I propose removing it for FreeBSD 14. I know the CHERI folks have been
using it but they plan to migrate away from it. It was broken for
months before they fixed it, so I suspect nobody is using it on
contemporary releases.

I have review D32707 (https://reviews.freebsd.org/D32707) open to add
this deprecation notice to the man page:
  The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
  smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not
  present in FreeBSD 14 and above.  Users are advised to evaluate the
  sysutils/fusefs-smbnetfs port instead.

A similar notice would be added to the smbutil and mount_smbfs man
pages, and manu@ suggested having the userland utilities emit a
warning when they are used.

I am interested in comments, objections, or reports that anyone is in
fact using smbfs.


I thought I'd mention the SMB client in illumos which is originally
based on FreeBSD one, imported and enhanced by Apple, then imported by
Sun, and finally updated to support SMB2/SMB3 in illumos.  It has a lot
of CDDL code now, but as ZFS shows it's not really a stopper.

ISTR there is (was?) also an Apple SMB client (based on FreeBSD)
somewhere on their "opensource" site.

Just saying that there are other options if someone(TM) is interested in
doing the work.


Apple sources can be found there 
https://opensource.apple.com/source/smb/ 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.


Miroslav Lachman

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

[Yuri]

Ed Maste wrote:
> The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and
> I propose removing it for FreeBSD 14. I know the CHERI folks have been
> using it but they plan to migrate away from it. It was broken for
> months before they fixed it, so I suspect nobody is using it on
> contemporary releases.
> 
> I have review D32707 (https://reviews.freebsd.org/D32707) open to add
> this deprecation notice to the man page:
>  The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
>  smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not
>  present in FreeBSD 14 and above.  Users are advised to evaluate the
>  sysutils/fusefs-smbnetfs port instead.
> 
> A similar notice would be added to the smbutil and mount_smbfs man
> pages, and manu@ suggested having the userland utilities emit a
> warning when they are used.
> 
> I am interested in comments, objections, or reports that anyone is in
> fact using smbfs.

I thought I'd mention the SMB client in illumos which is originally
based on FreeBSD one, imported and enhanced by Apple, then imported by
Sun, and finally updated to support SMB2/SMB3 in illumos.  It has a lot
of CDDL code now, but as ZFS shows it's not really a stopper.

ISTR there is (was?) also an Apple SMB client (based on FreeBSD)
somewhere on their "opensource" site.

Just saying that there are other options if someone(TM) is interested in
doing the work.

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

[Tomoaki AOKI]

On Sun, 31 Oct 2021 18:15:25 +0100
Marek Zarychta  wrote:

> W dniu 29.10.2021 o〓08:29, Andrea Venturoli pisze:
> >
> > On 10/29/21 00:47, Tomoaki AOKI wrote:
> >
> >> But possibly we need to delete current smbfs code from base and switch
> >> to ports (sysutils/*?) if it require some code having incompatible
> >> license for base.
> >
> +1 for removing smbfs(5) from the base and eventually moving it to the 
> ports tree. I know some people are still using it with a bit of duct 
> tape and baling twine to workaround〓 SMBv{2,3) incompatibility.

Keeping this in base as long as possible should be preferred, as
changes throuout all filesystems would be easier to be missed that on
ports. But borrowing GPL'ed (or any other BSD-incompatible licensed)
codes would disallow it.


> With SMBv1 support, only our smbfs(5) became useless a few years ago. 

No. It's much better than nothing.
For example, DSM on Synology NAS disabled support for SMB1 and NTLM1 by
default, but admin can easily enable them again through control panel.
So it's usable (for local networks) at least for now.


> Unfortunately, there is no replacement in the ports tree. To mount SMB 
> shares for Nextcloud the port net/pecl-smbclient can be used, but 
> definitely deploying Nextcloud to mount only SMB shares is overkill.
> 
> > OTOH having a port is not in any way worse as having a broken piece of 
> > base.
> 
> It sounds reasonable. Moreover, the story of net/wireguard-kmod has 
> proven that moving some modules into ports, where the software 
> development is done in a more flexible way, can be beneficial for both: 
> the developers and the community.
> 
> My opinion is only the opinion of the FreeBSD user, but I believe that 
> sometimes the feedback from the userbase is important, especially that a 
> few months I was told by one of the younger *NIX admins that our 
> (FreeBSD) community is the best and he is willing to make a transition 
> of some services to FreeBSD as soon as he gets permission from the 
> management.
> 
> With kind regards,
> 
> -- 
> Marek Zarychta
> 
> 


-- 
Tomoaki AOKI

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

[Marek Zarychta]

W dniu 29.10.2021 o 08:29, Andrea Venturoli pisze:


On 10/29/21 00:47, Tomoaki AOKI wrote:


But possibly we need to delete current smbfs code from base and switch
to ports (sysutils/*?) if it require some code having incompatible
license for base.


+1 for removing smbfs(5) from the base and eventually moving it to the 
ports tree. I know some people are still using it with a bit of duct 
tape and baling twine to workaround  SMBv{2,3) incompatibility.


With SMBv1 support, only our smbfs(5) became useless a few years ago. 
Unfortunately, there is no replacement in the ports tree. To mount SMB 
shares for Nextcloud the port net/pecl-smbclient can be used, but 
definitely deploying Nextcloud to mount only SMB shares is overkill.


OTOH having a port is not in any way worse as having a broken piece of 
base.


It sounds reasonable. Moreover, the story of net/wireguard-kmod has 
proven that moving some modules into ports, where the software 
development is done in a more flexible way, can be beneficial for both: 
the developers and the community.


My opinion is only the opinion of the FreeBSD user, but I believe that 
sometimes the feedback from the userbase is important, especially that a 
few months I was told by one of the younger *NIX admins that our 
(FreeBSD) community is the best and he is willing to make a transition 
of some services to FreeBSD as soon as he gets permission from the 
management.


With kind regards,

--
Marek Zarychta

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

[Shawn Webb]

On Fri, Oct 29, 2021 at 11:59:40AM +0100, David Chisnall wrote:
> On 28/10/2021 16:26, Shawn Webb wrote:
> > I wonder if providing a 9pfs client would be
> > a good step in helping deprecate smbfs.
> 
> Note: WSL2 uses 9p-over-VMBus, but most of the Linux world is moving away
> from 9p-over-VirtIO to FUSE-over-VirtIO.  This has a few big advantages:
> 
>  - The kernel already has solid FUSE support so this isn't a completely new
> code path.
> 
>  - FUSE is designed around POSIX filesystem semantics, 9p isn't and this
> mismatch causes problems in places.
> 
>  - FUSE filesystems can be exposed almost directly to the guest.  For
> example, if you have a networked filesystem you can run the FUSE FS in an
> unprivileged userspace process and remove the entire host kernel storage
> stack from the attack surface for the guest.
> 
>  - FUSE allows exposing buffer cache pages.  The FUSE-over-VirtIO mechanism
> makes it fairly easy to expose read-only root filesystem images to guests.
> 
> The last point is especially important for container workloads where you may
> have hundreds of containers in lightweight VMs on a single node all using
> the same base layer.

That's really cool. I hadn't heard about FUSE-over-VirtIO before.
Thanks for the info!

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

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

[David Chisnall]

On 28/10/2021 16:26, Shawn Webb wrote:

I wonder if providing a 9pfs client would be
a good step in helping deprecate smbfs.


Note: WSL2 uses 9p-over-VMBus, but most of the Linux world is moving 
away from 9p-over-VirtIO to FUSE-over-VirtIO.  This has a few big 
advantages:


 - The kernel already has solid FUSE support so this isn't a completely 
new code path.


 - FUSE is designed around POSIX filesystem semantics, 9p isn't and 
this mismatch causes problems in places.


 - FUSE filesystems can be exposed almost directly to the guest.  For 
example, if you have a networked filesystem you can run the FUSE FS in 
an unprivileged userspace process and remove the entire host kernel 
storage stack from the attack surface for the guest.


 - FUSE allows exposing buffer cache pages.  The FUSE-over-VirtIO 
mechanism makes it fairly easy to expose read-only root filesystem 
images to guests.


The last point is especially important for container workloads where you 
may have hundreds of containers in lightweight VMs on a single node all 
using the same base layer.


David

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

[Andrea Venturoli]

On 10/29/21 00:47, Tomoaki AOKI wrote:


But possibly we need to delete current smbfs code from base and switch
to ports (sysutils/*?) if it require some code having incompatible
license for base.


I normally favour ports over things in base.
In this case, however, as I said before, I needed it several times in 
emergency while booting the install key as live media.

If it's a port, it won't be there.
Perhaps my use case is rare. Also, probably there are other tools that 
can do this.


OTOH having a port is not in any way worse as having a broken piece of base.

 bye
av.

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

[Tomoaki AOKI]

On Thu, 28 Oct 2021 17:37:33 +0200
Miroslav Lachman <000.f...@quip.cz> wrote:

> On 28/10/2021 16:44, Ed Maste wrote:
> > The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and
> > I propose removing it for FreeBSD 14. I know the CHERI folks have been
> > using it but they plan to migrate away from it. It was broken for
> > months before they fixed it, so I suspect nobody is using it on
> > contemporary releases.
> > 
> > I have review D32707 (https://reviews.freebsd.org/D32707) open to add
> > this deprecation notice to the man page:
> >   The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
> >   smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not
> >   present in FreeBSD 14 and above.  Users are advised to evaluate the
> >   sysutils/fusefs-smbnetfs port instead.
> > 
> > A similar notice would be added to the smbutil and mount_smbfs man
> > pages, and manu@ suggested having the userland utilities emit a
> > warning when they are used.
> > 
> > I am interested in comments, objections, or reports that anyone is in
> > fact using smbfs.
> 
> I am working for one company where smbfs is heavily used to connect 
> Windows / MacOS / Linux / FreeBSD (12.2) machines and we are really sad 
> that FreeBSD's mount_smbfs does not support SMBv2 / SMBv3 protocols (so 
> we are using SMBv1 with all the risk). I tried fusefs alternatives from 
> the ports tree in the past but it never worked as is needed. From our 
> point of view smbnetfs cannot replace mount_smbfs.
> I cannot found any good examples of how to configure it to mount about 
> 20 shares from /etc/fstab on boot as user root from different hosts with 
> different login, passwords and mount options to defined mount points.
> Everything seems to be very differently designed to work for non-root 
> user with configuration in users home, not system wide and mounting in 
> some strange hierarchy. (and bad performance was cited by many on other 
> platforms too)

I, as an end-user who need to access local NAS, tried it a few yearsago
(when it once broken by struct sockbuf issue that I finally
sent patch) and had concluded smbnetfs is unusable for me.
Additionally, it was quite unstable ATM. Sudden forcible unmount and
failing remount.

If it worked as expected, I wouldn't have tried digging into and sent
Bug 182963.

BTW, current in-tree code is broken for me and mandated patch proposed
on Bug 90815. There are 3 patches uploaded and I use second one for
years. Third one worked, too when I tried, but not continually using.
The first one would no longer applicable.


> It was discussed in the past in some other FreeBSD mailinglist that it 
> is not so easy to implement SMBv2 in to mount_smbfs. But is there any 
> possibility to make it as some sponsored work? What about FreeBSD 
> Foundation? There were some paid projects in the past. Or some other 
> bounty program. Is there anybody who have the skill to implement it if 
> there is good amount of $?

+1 for FreeBSD Foundation project.
But possibly we need to delete current smbfs code from base and switch
to ports (sysutils/*?) if it require some code having incompatible
license for base.

Anyway, please don't remove it unless usable alternative appears.


> If I am "well informed" FreeBSD is the only widely used OS not 
> supporting SMBv2. (MacOS, Linux, Solaris have it supported)
> I will be really glad "if somebody can fix it" in the base.
> 
> (or at least document how to use smbnetfs the way mount_smbfs is used)
> 
> Kind regards
> Miroslav Lachman
> 


-- 
Tomoaki AOKI

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

[Brooks Davis]

On Thu, Oct 28, 2021 at 09:33:18PM +0200, Miroslav Lachman wrote:
> On 28/10/2021 18:25, Ed Maste wrote:
> > On Thu, 28 Oct 2021 at 11:05, Eugene Grosbein  wrote:
> >>
> >> Please do not remove what is not broken.
> > 
> > That is exactly the problem though: it was broken. It was fixed only
> > because the CHERI folks found that it wasn't working and fixed it, and
> > they are not going to be using it much longer. If nobody else
> > regularly tests it in -CURRENT it will break again, and will end up
> > broken in a release.
> 
> Can this problem be covered by some automated tests to catch it sooner - 
> before release?

FWIW, any testing at all would have caught this.  It paniced on unmount
in a kernel with INVARIANTS.  The awkward thing about testing it is that
it requires a server.  We'd have caught it sooner if we hadn't had a
major stall in merging FreeBSD head to CheriBSD.

We're hoping to stop using it because it's slow, server support will
eventually go away, etc.  We don't really have an opinion about it
staying or going.

-- Brooks


signature.asc
Description: PGP signature

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

[Miroslav Lachman]

On 28/10/2021 18:25, Ed Maste wrote:

On Thu, 28 Oct 2021 at 11:05, Eugene Grosbein  wrote:


Please do not remove what is not broken.


That is exactly the problem though: it was broken. It was fixed only
because the CHERI folks found that it wasn't working and fixed it, and
they are not going to be using it much longer. If nobody else
regularly tests it in -CURRENT it will break again, and will end up
broken in a release.


Can this problem be covered by some automated tests to catch it sooner - 
before release?



That said, since it does seem that several folks
are still currently using i I'll avoid trying to remove it in the near
future.

A caveat for the man pages may instead be something like:

 The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
 smbfs is unmaintained and may not function correctly in FreeBSD 14 or
 later.  Users are advised to evaluate the sysutils/fusefs-smbnetfs port
 instead. 


Kind regards
Miroslav Lachman

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

[Gleb Popov]

On Thu, Oct 28, 2021 at 6:39 PM Miroslav Lachman <000.f...@quip.cz> wrote:

> I am working for one company where smbfs is heavily used to connect
> Windows / MacOS / Linux / FreeBSD (12.2) machines and we are really sad
> that FreeBSD's mount_smbfs does not support SMBv2 / SMBv3 protocols (so
> we are using SMBv1 with all the risk). I tried fusefs alternatives from
> the ports tree in the past but it never worked as is needed. From our
> point of view smbnetfs cannot replace mount_smbfs.
> I cannot found any good examples of how to configure it to mount about
> 20 shares from /etc/fstab on boot as user root from different hosts with
> different login, passwords and mount options to defined mount points.
> Everything seems to be very differently designed to work for non-root
> user with configuration in users home, not system wide and mounting in
> some strange hierarchy. (and bad performance was cited by many on other
> platforms too)
> It was discussed in the past in some other FreeBSD mailinglist that it
> is not so easy to implement SMBv2 in to mount_smbfs. But is there any
> possibility to make it as some sponsored work? What about FreeBSD
> Foundation? There were some paid projects in the past. Or some other
> bounty program. Is there anybody who have the skill to implement it if
> there is good amount of $?
>
> If I am "well informed" FreeBSD is the only widely used OS not
> supporting SMBv2. (MacOS, Linux, Solaris have it supported)
> I will be really glad "if somebody can fix it" in the base.
>
> (or at least document how to use smbnetfs the way mount_smbfs is used)
>
> Kind regards
> Miroslav Lachman
>
>
I'm also aware of a local company that actively uses smbfs. Removing it
would probably cause them to switch to Linux, which is a pity.

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

[Ed Maste]

On Thu, 28 Oct 2021 at 11:26, Shawn Webb  wrote:
>
> It seems that smbfs might be used with some level of frequency in
> virtualized environments. I wonder if providing a 9pfs client would be
> a good step in helping deprecate smbfs.

Indeed, that addresses one of the primary reasons it is still being
used, including by CHERI. Their plan to migrate away from smbfs is
based on moving to 9pfs.

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

[Ed Maste]

On Thu, 28 Oct 2021 at 11:05, Eugene Grosbein  wrote:
>
> Please do not remove what is not broken.

That is exactly the problem though: it was broken. It was fixed only
because the CHERI folks found that it wasn't working and fixed it, and
they are not going to be using it much longer. If nobody else
regularly tests it in -CURRENT it will break again, and will end up
broken in a release. That said, since it does seem that several folks
are still currently using i I'll avoid trying to remove it in the near
future.

A caveat for the man pages may instead be something like:

The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
smbfs is unmaintained and may not function correctly in FreeBSD 14 or
later.  Users are advised to evaluate the sysutils/fusefs-smbnetfs port
instead.

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

[Miroslav Lachman]

On 28/10/2021 16:44, Ed Maste wrote:

The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and
I propose removing it for FreeBSD 14. I know the CHERI folks have been
using it but they plan to migrate away from it. It was broken for
months before they fixed it, so I suspect nobody is using it on
contemporary releases.

I have review D32707 (https://reviews.freebsd.org/D32707) open to add
this deprecation notice to the man page:
  The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
  smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not
  present in FreeBSD 14 and above.  Users are advised to evaluate the
  sysutils/fusefs-smbnetfs port instead.

A similar notice would be added to the smbutil and mount_smbfs man
pages, and manu@ suggested having the userland utilities emit a
warning when they are used.

I am interested in comments, objections, or reports that anyone is in
fact using smbfs.


I am working for one company where smbfs is heavily used to connect 
Windows / MacOS / Linux / FreeBSD (12.2) machines and we are really sad 
that FreeBSD's mount_smbfs does not support SMBv2 / SMBv3 protocols (so 
we are using SMBv1 with all the risk). I tried fusefs alternatives from 
the ports tree in the past but it never worked as is needed. From our 
point of view smbnetfs cannot replace mount_smbfs.
I cannot found any good examples of how to configure it to mount about 
20 shares from /etc/fstab on boot as user root from different hosts with 
different login, passwords and mount options to defined mount points.
Everything seems to be very differently designed to work for non-root 
user with configuration in users home, not system wide and mounting in 
some strange hierarchy. (and bad performance was cited by many on other 
platforms too)
It was discussed in the past in some other FreeBSD mailinglist that it 
is not so easy to implement SMBv2 in to mount_smbfs. But is there any 
possibility to make it as some sponsored work? What about FreeBSD 
Foundation? There were some paid projects in the past. Or some other 
bounty program. Is there anybody who have the skill to implement it if 
there is good amount of $?


If I am "well informed" FreeBSD is the only widely used OS not 
supporting SMBv2. (MacOS, Linux, Solaris have it supported)

I will be really glad "if somebody can fix it" in the base.

(or at least document how to use smbnetfs the way mount_smbfs is used)

Kind regards
Miroslav Lachman

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

[Shawn Webb]

On Thu, Oct 28, 2021 at 10:44:56AM -0400, Ed Maste wrote:
> The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and
> I propose removing it for FreeBSD 14. I know the CHERI folks have been
> using it but they plan to migrate away from it. It was broken for
> months before they fixed it, so I suspect nobody is using it on
> contemporary releases.
> 
> I have review D32707 (https://reviews.freebsd.org/D32707) open to add
> this deprecation notice to the man page:
>  The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
>  smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not
>  present in FreeBSD 14 and above.  Users are advised to evaluate the
>  sysutils/fusefs-smbnetfs port instead.
> 
> A similar notice would be added to the smbutil and mount_smbfs man
> pages, and manu@ suggested having the userland utilities emit a
> warning when they are used.
> 
> I am interested in comments, objections, or reports that anyone is in
> fact using smbfs.
> 

It seems that smbfs might be used with some level of frequency in
virtualized environments. I wonder if providing a 9pfs client would be
a good step in helping deprecate smbfs.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Deprecating smbfs(5) and removing it before FreeBSD 14

[Ed Maste]

The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and
I propose removing it for FreeBSD 14. I know the CHERI folks have been
using it but they plan to migrate away from it. It was broken for
months before they fixed it, so I suspect nobody is using it on
contemporary releases.

I have review D32707 (https://reviews.freebsd.org/D32707) open to add
this deprecation notice to the man page:
 The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
 smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not
 present in FreeBSD 14 and above.  Users are advised to evaluate the
 sysutils/fusefs-smbnetfs port instead.

A similar notice would be added to the smbutil and mount_smbfs man
pages, and manu@ suggested having the userland utilities emit a
warning when they are used.

I am interested in comments, objections, or reports that anyone is in
fact using smbfs.