How hard would it be to implement the server side of the protocol?

[majortom64]

I am interested in a pure swift implementation of SMB 3’s server side protocol and wanted to know how hard you thought it would be implement.

[kishikawakatsumi]

The level of complexity depends on the scale you're aiming for, but server-side implementation is significantly more difficult than client-side. This is because while a client only needs to manage its own state, an SMB server must properly manage numerous states—multiple clients, sessions, file systems, and authentication—which are incomparably more complex than those of a single client.

[majortom64]

Just looking for the server side part of SMB 3, not a full samba server. This is not a replacement for Samba, but the minimum set of functionality needed for a small embedded device. Ideally, it can support the encrypted version of the protocol, but it does not need any authentication (unless there is some easy to implement very basic auth), and it does not need to manage file systems (that would be handled by something else).

[kishikawakatsumi]

Just to check we’re on the same page, it sounds like you want:

• a minimal SMB3 server-side library for an embedded device (not a full Samba replacement)
• SMB3 encryption if possible
• no full auth system (no AD/Kerberos, no user DB)
• the library should not implement a filesystem, but call your code for open/read/write/close

Two important points I want to make sure we both understand:

• In SMB3, encryption is tied to authentication – you normally need at least some kind of auth step to derive a session key for encryption. We could maybe do something very simple (e.g. a single fixed “guest” user or pre-shared key), but “encrypted with absolutely no auth” isn’t how standard SMB3 works.
• “Not managing the filesystem” is fine if the library still keeps SMB-level state (sessions, tree IDs, handles) and simply forwards file operations to your callbacks.

A couple of quick questions to align requirements:

1. Do you need this to work with standard Windows/macOS SMB clients, or will you also control the client side?
2. Would a model with a single fixed identity / pre-shared key + encryption + callback-based file I/O match what you have in mind?

If this sounds right, I can think about what a realistic minimal subset would look like.

[majortom64]

Yes, my starting point is an embedded SMB 3 server side implementation. While there is no plan past that, an implementation that does not needlessly close off expanding its scope later would be better that one that could not be expanded (if that makes sense).

SMB3 encryption would be great. Any way to get there is fine whether that means a pre-shared key or a dummy auth flow (plain text send the user and password and always work) would all be fine. Ideally, having stub where one would later add some other auth would be great, but not required for MVP.

No auth integration is needed. That will be a future project if things get that far. :-)

Yes, it does not need to implement a filesystem. My expectation is that I will integrate with SwiftNIO’s Filesystem API. https://swiftonserver.com/nio-file-system.

Yes, any dummy auth flow will work for the encryption implementation (at some point I will probably add some real auth flow, but that is a problem for future me). :-)

It should work with a regular SMB client (even if that means always using the same hardcoded user/password combination).

Yes, a pre-shared password would be fine as a starting point.

One last point. It should be written to support Swift 6 (and if possible), 6.2.