Feature #9735
closed
Need to provide SMB 2.1 Client
100%
Description
The kernelbased SMB server needs some enhancements like
- connect and join domain when SMB1 is disabled
- add SMB3 support
Related issues
Updated by Jorge Schrauwen over 4 years ago
A good starting point is probably cherry picking a lot of the nexenta SMB changes from https://github.com/Nexenta/illumos-nexenta/commits/master
Updated by Gordon Ross over 4 years ago
- Subject changed from Connect when SMB1 is disabled and add SMB3 to Need to provide SMB 2.1 Client
Actually, the place from which to cherry pick is this branch:
https://github.com/Nexenta/illumos-nexenta/commits/release-4.0.5-FP
I'm working on getting the SMB 2.1 client integrated.
I'll use this issue for it, making it specific to that task.
Updated by Gordon Ross over 4 years ago
- Status changed from New to In Progress
- Assignee set to Gordon Ross
- % Done changed from 0 to 90
- Estimated time set to 500.00 h
- Tags deleted (
needs-triage)
Updated by Gordon Ross over 4 years ago
Up for review over here: https://github.com/illumos/illumos-gate/pull/37
There's a whole lot of new code here. The design largely follows what was there for SMB1.
A few pieces were taken from the Apple SMB client (which shares a common ancestor with the illumos client code).
Updated by Vitaliy Gusev over 4 years ago
Gordon, why the current design for smb/smb2 client has some part in user space (libs and smbiod) and some part in kernel space (nsmb module) ? Why don't whole SMB/SMB2 client functionality is not placed in user space ?
Updated by Gordon Ross over 4 years ago
That's a good question. It's a good piece of general guidance that when things can be done in user space, that's best.
If we were only interested in letting the SMB server make connections out to an AD server, we might have used an "in process" SMB client (running as a part of smbd in user-space, for example).
However, the existing design (before the SMB2 client work) also had another functionality goal which was to provide a full-featured SMB client implementation for mounting SMB shares. By "full-featured", I mean the ability to present full "meta-data" including ACLs, extended attributes (i.e. DOS Archive Hidden RO,... bits) and named streams.
One reason for this goal is so that the SMB client can be used for data migration from an existing SMB server without losing meta-data during the migration.
We made the choice to extend the existing architecture rather than replace it with an all user-space one.
With the introduction of the "fksmbcl" development tool, we still enjoy many of the features of user-space development anyway.
Updated by Gordon Ross about 4 years ago
- Subject changed from Need to provide SMB 2.1 Client to Need to provide SMB 2.1 Client
Updated by Electric Monk about 4 years ago
- Status changed from In Progress to Closed
- % Done changed from 90 to 100
git commit adee678425979226b2b55d1a0b39ce4c989382e9
commit adee678425979226b2b55d1a0b39ce4c989382e9
Author: Gordon Ross <gwr@nexenta.com>
Date: 2019-03-14T14:38:30.000Z
9735 Need to provide SMB 2.1 Client
Reviewed by: Evan Layton <evan.layton@nexenta.com>
Reviewed by: Matt Barden <matt.barden@nexenta.com>
Reviewed by: Rick McNeal <rick.mcneal@nexenta.com>
Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com>
Reviewed by: Joyce McIntosh <joyce.mcintosh@nexenta.com>
Approved by: Joshua M. Clulow <josh@sysmgr.org>
Updated by x v about 4 years ago
Just a nit -- this integration added a bit of cruft:
usr/src/lib/smbclnt/libfknsmb/common/llib-lfknsmb usr/src/lib/smbclnt/libfksmbfs/common/llib-lfksmbfs
Updated by Gergő Mihály Doma about 4 years ago
- Related to Bug #11071: unused files after 9735 added