Talk:Server Message Block/Archive 1

Archive 1

Page cleaned up a little

I tried to clean up this page a little, as it was tagged for such, but I don't get to edit often, so I don't know if it's enough. I've added headings to separate out parts of the article from each other, and I added a little about samba in the history section... anything else? — Preceding unsigned comment added by Aitrus56 (talk • contribs) 21:58, 23 September 2005 (UTC)

Does someone hate Advanced Server or what?

The comments about the SMB server code for System V are hardly neutral. — Preceding unsigned comment added by Mre5765 (talk • contribs) 00:37, 30 October 2005 (UTC)

Legally authoritative

Finkelstein's "Report on Microsoft Work Group Server Protocol Programme: An Assessment of Interoperability Information" links to this article in Annex B9. Metarhyme 00:41, 24 February 2006 (UTC)

Server Message Block should be capitalized

As per capitalization, refer to:

• Wikipedia:Naming conventions (capitalization)
• Wikipedia:Naming conventions

Nixdorf 18:19, 29 Feb 2004 (UTC)

But that doesn't trump common usage. If you google for "Server Message Block" and "Common Internet File System" you will find the versions with the capitals frequently used and the lowercase versions very rarely used. Morwen 18:22, Feb 29, 2004 (UTC)

You shall not strive to sink yourself to the least common denominator of common language use, you shall strive to elevate others to the high level of your own language use. Nixdorf 23:30, 29 Feb 2004 (UTC)

Nothing in those documents dictates that "Server Message Block" should not be capitalized as such. "Server Message Block" is a name. Official Microsoft documentaion has it capitalized, IETF documents have it capitalized, Samba has it capitalized. To not capitalize it is improper. Iambk 04:39, 12 December 2006 (UTC)

1. Server Message Block and Common Internet File System are proper nouns. 2. Articles discussing other protocols capitalize all the words in their names. See Transmission Control Protocol, Internet Protocol, etc.

I agree wholeheartedly. I have never seen Server Message Block written in lower-case (besides on Wikipedia). In addition to your reasons, Wikipedia:Naming conventions says "Do not capitalize second and subsequent words unless the title is a proper noun (such as a name) or is otherwise almost always capitalized" (emphasis mine). I'm going to make this move. -- Plutor 14:39, 4 August 2005 (UTC)

OSI table would add clarity.

I would like an OSI model table here to show where the different parts of SMB and it's related protocols operate. Thanks -indolering

Look to this URL for that first. There is a good reason this is number one in a Google search (but it may violate your GFDL restriction):

 http://samba.anu.edu.au/cifs/docs/what-is-smb.html

Does that help? SMB is at the Application and Presentation layers. Actually, what led me here was a statement in ComputerWorld with some Microsoft idiot not knowing where SMB came from. IBM! I was going to retort to them that rather than using Samba I have used pcnfsd on Sun Solaris for the file serving. Right now I print to a Minolta Page Pro 1350W printer through a Zonet ZPS-2102 print server. Ever try to find what the driver files for it are on Windows? It is using IPP on Windows and (CUPS) on Linux. The biggest problem is that Microsoft demands a print server name it's own way rather than allowing the user to change it. So on Windows it shows up as Unknown with the name pagepro only being able to be inserted via adding it to the hosts file and using that instead of the IP address of the Zonet server. Go figure. hhhobbit 20:27, 28 September 2007 (UTC)

application-level network protocol

In the first paragraph, it mentioned SMB is application-level network protocol. Is it referring to the application layer in OSI seven layer model?

Stephenchao 05:58, 20 April 2007 (UTC)Stephenchao

According to 3Com's WestNet program SMB is presentation-layer according to the OSI model. —Preceding unsigned comment added by 207.157.211.23 (talk) 23:18, 29 October 2007 (UTC)

Bugs and corruption

It's only a minor point, but I'd also mention that SMB has been a weak point in the MS stack, particularly with the major file corruption problems with the Windows 2000 release (which were fixed in a critical security update, so don't go looking for the patch). —Preceding unsigned comment added by 150.101.166.15 (talk) 03:07, 19 September 2008 (UTC)

More History

My recollection is the SMB term was used to describe the file-sharing protocol employed by the MS-DOS 3.X "redirector" client and its companion "MSNet" server. Manufacturers shipping SMB-based networks may include 3-COM, HP and IBM. The LAN Manager term was in regular use during the development of the OS/2 and the LAN Manager/X (LM/X, a predecessor of SAMBA) server during the 1980s (well before 1990 as the article indicates). Conr2286 (talk) 00:33, 20 November 2008 (UTC)

Performance Issues

Edited this section to remove the chip-on-shoulder "administrative ignorance" rant.

change of subject (points of interest):

Packet signing affects performance. There are three reasons for this.

1 Extra overhead, prevention of offloading. [1] is just one of many MS sources that says that "Using SMB packet signing can degrade performance up to 15 percent on file service transactions.". This is worth remembering, but in practice no-one cares.

2 Man-in-the-middle compression appliances are broken. Only affects people who use network appliances to improve throughput.

3 Increased latency. [2] is one of the few MS sources which address this, [3],[4]. The bug was delayed ACK, but even when the system is not broken, it still enforces serialisation. —Preceding unsigned comment added by 218.214.18.240 (talk) 08:34, 28 February 2009 (UTC)

SMB and CIFS

The article says: At around the time when Sun Microsystems announced WebNFS [1], Microsoft launched an initiative in 1996 to rename SMB to Common Internet File System (CIFS)[1], and added more features, including support for symbolic links, hard links, larger file sizes and an attempt at supporting direct connection without all the NetBIOS trimmings — an effort that was largely experimental and required further refinement. Microsoft submitted the spec to the IETF[2], though this submission has expired.

Did it actually change name to CIFS? Is SMB just a legacy name? Why is the article not called CIFS? What does it mean that the submission of the "spec" has expired?

The reference links are not working.

Velle 13:49, 11 January 2007 (UTC)

The only link I noticed was stale is the Microsoft link. Since you mentioned it in January and it is now September will the primary care-taker of this page please edit that link out?

hhhobbit 20:33, 28 September 2007 (UTC)

CIFS is *based on* SMB ... "CIFS is an enhanced version of Microsoft's open, cross-platform Server Message Block (SMB) protocol" http://www.microsoft.com/mind/1196/cifs.asp

My first instinct was "yes" this page should be renamed, but there are two issues... 1) There are many mentions of SMB that you'd have to modify 2) Actually SMB is NOT CIFS, just a very similar predecessor

At the end of the day the more correct solutions would be either 1) (QUICKER) a single page called CIFS_and_SMB that covers both topics, explaining the differences, with redirects from both CIFS and SMB 2) (BETTER) Individual articles on CIFS and SMB that split the relevant information from this page accordingly, but that both refer to each other and explain the differences

PS: I have checked some of the reference links and from my sample they seem to have been fixed up

Artemgy 16:27, 23 March 2007 (UTC)

SMB is a protocol that's had many updates. The SNIA CIFS spec includes some messages from various versions of the protocol, plus some extensions, and also includes the non-NetBIOS encapsulation atop TCP (port 445). It doesn't include all of the messages that have ever been part of SMB, and I think there might have been messages added to SMB by Microsoft Vista, after the SNIA spec came out.

So saying SMB is "a very similar predecessor" to CIFS is misleading; some of the "similarities" are, in fact, identical messages (not just similar messages), and Microsoft have, I think, made additions to SMB after the SNIA CIFS spec came out (so SMB isn't just a predecessor). Guy Harris 21:02, 23 March 2007 (UTC)

The way I'd describe it is that Microsoft took a point-in-time snapshot of (a part of; it is by no means complete) the SMB protocol, wrote it up as a proposal called CIFS, and then eventually abandoned it. There were revisions of SMB before that, and there have been revisions of SMB since then. I believe the protocol documentation can now actually be obtained from MSDN, and it is referred to as SMB. Meanwhile, Microsoft has announced SMB2, which is a redesign of the protocol for the modern world, jettisoning a lot of the old baggage. —Preceding unsigned comment added by 70.88.209.29 (talk) 20:26, 24 April 2009 (UTC)

Interesting History

From [http://ubiqx.org/cifs/SMB.html]

From:	Steven French, Senior Software Engineer, IBM	
To:	Chris Hertel	

Chris, 

Hope things are going well in the cold north ...  

I thought the following info would be interesting to you. I 
met the original "inventor" of SMB a  few years ago - Dr. 
Barry Feigenbaum - who back in the early 80's was working on 
network software architecture for the infant IBM PCs,  
working for IBM in the Boca Raton plant in Florida. He 
mentioned that it was first called the "BAF" protocol (after 
his initials) but he later changed it to SMB. In the early 
DOS years IBM and Microsoft (with some input from Intel and 
3Com) contributed to it but by the time of the first OS/2 
server version (LANMAN1.0 dialect and later) Microsoft did 
much of the work (for "LAN Manager" and its relatives).

In [[5]] (sorry, it's German) a Samba developer makes it clear that Samba predates SMB support in Windows, so the corresponding paragraph in the article is misleading.

Rewritten a bit, to reflect what Tridge wrote in his short history of the early days of Samba. Guy Harris (talk) 01:38, 27 July 2011 (UTC)

If Lion is SMB2-only, how can it work with Windows XP?

The cited AnandTech article says:

Lion’s new SMB implementation is SMB 2.0 only - this is a Microsoft-developed improvement of the specification that was introduced in Windows Vista and continued in Windows 7.

and

SMB’s main use in OS X is for file sharing with Windows users, though, and I can say that file sharing with users of both Windows XP and Windows 7 (and, by extension, Windows Vista, for what it’s worth) works just fine once you set it up in System Preferences. I was able to copy files to and from a basic share I made without issue.

which means either that SMB 2.0 was not introduced in Vista, but in XP, or that Lion's SMB server is not SMB 2.0 only. SMB1 has multiple dialects, and perhaps Lion's SMB server dropped support for older dialects, as well as dropping support for the pre-Active Directory domain system, and might also have dropped support for older authentication mechanisms, just as Lion's AFP server did. Guy Harris (talk) 17:20, 7 September 2011 (UTC)

WinXP can't talk SMB2. SMB 1.0 is the lowest common denominator for systems that are able to talk SMB2 - so if SMB2 negotiation fails, then the parties simply fall back to SMB 1.0. Sniff some network traffic and you'll see. 119.225.177.168 (talk) 10:06, 8 September 2011 (UTC)

In other words, as I knew to be the case, the claim that Lion is SMB2-only is wrong. Out it goes. Guy Harris (talk) 17:08, 8 September 2011 (UTC)

The correction would surely be to say that Lion supports SMB2, rather than Lion supporting only SMB2? In any event we need a ref. Socrates2008 (Talk) 22:50, 8 September 2011 (UTC)

The correction would only be to say that Lion supports SMB2 if, in fact, it supports SMB2. I have seen no references to indicate that Lion supports SMB2, much less that it dropped support for SMB1; absent that, no claims about Lion and SMB2 should be made in the article. Guy Harris (talk) 23:06, 8 September 2011 (UTC)

And a reference needs to do more than just assert, with no evidence such as a statement from Apple or a network trace, that Lion supports SMB2 or only supports SMB2. Guy Harris (talk) 01:41, 9 September 2011 (UTC)

OS X uses the Samba engine. See the section on Samba. It is technically Feature incomplete SMB3 with back-support for SMB2 and SMB1, and recently has added features to SMB4. Apple dropped it as a "supported feature" but last I checked you could still install it. Either way you can still install Samba on OS X, and any other OS that has a Posix compliant core. --Robert Wm "Ruedii" (talk) 03:04, 28 October 2012 (UTC)

Correction Samba is SMB2 with a handful added features from SMB3. It also implements SMB1, but that feature can be deactivated (and likely should be on most modern systems.) I'm not sure what features Apple's version is built with, or what features are enabled by default. I suspect it runs in SMB2 mode, as nothing really requires SMB1 anymore.

OS X Lion and Mountain Lion do not use Samba as their SMB server; if the section on Samba in any Wikipedia article claims they do, it needs to be fixed. Samba implemented SMB1 before SMB2 even existed, so saying it "also" implements SMB1 is a bit misleading. Saying it "is" SMB2 is incorrect - it "is" SMB, implementing the original version ("SMB1") and, in newer versions, SMB2 and some SMB3 features. Guy Harris (talk) 06:16, 28 October 2012 (UTC)

Bias favoring Microsoft SMB as "standard"

The article seems to repetitively imply that Microsoft SMB predates the IBM version of the protocol. Many times it goes beyond implying and directly credits the protocol to Microsoft, when that couldn't be further from the truth.

Furthermore, when mentioning the security flaw in the original password protocol, it fails to mention that the flaw was in Microsoft's implementation of the protocol, not the protocol itself.

Additionally, all of the reference links are to the Microsoft documentation, and not a single one to the Samba and RFC documentation of the protocol, both of which are far more detailed. --Robert Wm "Ruedii" (talk) 02:21, 28 October 2012 (UTC)

I see no places where it implies either that Microsoft SMB predated the IBM version nor that the protocol wasn't originally developed by IBM. It does state that most of the work on the protocol since the original IBM version was done by Microsoft, which is, in fact, true.

The Microsoft documentation is actually quite detailed, and, for better or worse, is the closest thing to "official" documentation. The only RFCs I know of that document anything related to SMB are RFC 1001 and RFC 1002, which actually document NetBIOS-over-TCP, atop which SMB runs; this page links to the NetBIOS over TCP/IP page which, in turn, links to those RFCs. If you think there are references from Samba that would also be useful, please add links to them. Guy Harris (talk) 17:34, 24 March 2013 (UTC)

The 2012 presentation by Samba's Steve French actually says: "SMB2 – Documented in unprecedented detail (for a network file system protocol) since 2007 (through WSPP), with test cases to prove docs right, and network analysis tools". So it may have been true that SMB1 was poorly documented by MS, but surely not SMB2. Someone not using his real name (talk) 02:20, 12 January 2014 (UTC)

WSPP refers to [6]; Mr. RuediiX should also refer to [7]. By the way, this info should probably be added to the article... Someone not using his real name (talk) 02:23, 12 January 2014 (UTC)

And there are pretty good SMB1 specs at WSPP as well, such as MS-CIFS and MS-SMB; SMB1 is MS-CIFS plus the additional stuff documented in MS-SMB. A bunch of the MS-RPC-based protocols that run atop SMB*n* are also documented there, and SMB2 and SMB3 are documented in MS-SMB2. Guy Harris (talk) 03:04, 12 January 2014 (UTC)

Split article? Or at least a major rewrite is needed

Given the vast differences between SMB and SMB2, an approach like a single "features" section is basically unintelligible. Someone not using his real name (talk) 01:50, 12 January 2014 (UTC)

Better now? (A year later.) -- Charles Edwin Shipp (talk) 04:22, 8 January 2015 (UTC)

Legal Challenges from DoJ & EU Forcing Openness

This article misses one of the biggest most interesting pieces of history entirely, and that's pretty embarrassing and inexcusable. The United states Department of Justice and the European Union successfully took Microsoft to court, and in both cases walked away with guarantees that Microsoft would open the protocol. Links: [8] [9] [10] [11]

This is super interesting, as it's one of the rare cases in history where governments have gotten deeply involved in taking a well used software protocol and increasing legal privilege to interoperate with that protocol. [12] here also has discussion about this mandatory "standization". -- Rektide (talk) 16:43, 8 May 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Server Message Block. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added {{dead link}} tag to http://www.tools.ietf.org/html/draft-heizer-cifs-v1-spec
• Added archive https://web.archive.org/web/20060505005515/http://blogs.msdn.com/chkdsk/archive/2006/03/10/548787.aspx to http://blogs.msdn.com/chkdsk/archive/2006/03/10/548787.aspx

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 12:53, 10 December 2017 (UTC)

I fixed the first one; the second one works. Guy Harris (talk) 18:02, 10 December 2017 (UTC)

CIFS != SMB

From a wiki contributer on this page: "CIFS is *based on* SMB ... "CIFS is an enhanced version of Microsoft's open, cross-platform Server Message Block (SMB) protocol" http://www.microsoft.com/mind/1196/cifs.asp"

Does this not mean, then, that CIFS should not route to this page, being a distinct implementation of SMB and an entirely separate logical entity altogether? In the least, if CIFS routes to this page, SMB, there should be a mention and helpful explanation of how "CIFS" is linked with "SMB". —The preceding unsigned comment was added by 204.248.57.243 (talk • contribs) 07:30, 12 July 2007 (UTC).

No, it does not, as it's not an "implementation of SMB" at all; it's a protocol specification of a protocol that's not "an entirely separate logical entity" from SMB, it's just one particular variant of SMB.

Microsoft's SMB IFS and SMB server code, Samba, smbfs and cifsfs for Linux, smbfs in various BSDs and OS X, etc. are implementations of SMB; a protocol specification isn't an implementation. SMB isn't a protocol with a single specification; the original SMB specification was extended with additional specifications. Various CIFS specifications have been issued, such as the one Microsoft issued (referred to by the cited Microsoft article), and the subsequent one from the SNIA at http://www.snia.org/tech_activities/CIFS; the Microsoft spec was largely a subset of the "NT" version of SMB, with a few additions.

So the discussion of CIFS on this page perhaps requires a bit more than just

At around the time when Sun Microsystems announced WebNFS [1], Microsoft launched an initiative in 1996 to rename SMB to Common Internet File System (CIFS)[1], and added more features, including support for symbolic links, hard links, larger file sizes and an attempt at supporting direct connection without all the NetBIOS trimmings — an effort that was largely experimental and required further refinement. Microsoft submitted some partial specifications as Internet-Drafts to the IETF[2], though these submissions have expired.

but that's pretty much what should be here. Guy Harris 19:58, 12 July 2007 (UTC)

So how do CIFS and SMB "not exactly equate to each other"? Guy Harris (talk) 20:22, 5 January 2008 (UTC)

http://msdn2.microsoft.com/en-us/library/aa302188.aspx Client systems use the CIFS (Common Internet File System) protocol to request file and print services from server systems over a network. It is based on the Server Message Block (SMB) protocol.

"Based on" does not mean "equate" If it did, it would make SCO's arguments valid. If Linux is was based on Unix it would be Unix and everyone owes them money. —Preceding unsigned comment added by 204.10.209.1 (talk) 18:04, 7 April 2008 (UTC)

I'm also of the view that CIFS is a new and separate entity. It may be based on and similar to SMB, but it isn't SMB... I note there are separate articles on Wikipedia for IPv4 and IPv6. See where that's going? Supertin (talk) 04:45, 29 July 2008 (UTC)

Although I agree that they're different, a quick google shows enough public confusion that it would at least warrant a cross reference. However, I doubt you could provide enough unique information to make the cross-reference worth reading in both places. I suggest a common article (this one's fine) that has a section to compare and contrast the two. KnockNrod (talk) 19:31, 19 December 2008 (UTC)

'CIFS' is the name of a protocol that Microsoft proposed for standardization in 1997 or thereabouts. It was based on the earlier SMB protocol. Subsequent to the abortive standardization attempt, Microsoft has continued to extend the SMB protocol, which it refers to as 'SMB'. So, properly speaking, no-one should be interested in CIFS, because there are likely no implementations that just speak exactly the protocol documented as CIFS. Nevertheless, those of us that write SMB implementations outside of Microsoft tend to say 'CIFS' rather more than is technically justifiable. —Preceding unsigned comment added by 70.88.209.29 (talk) 20:18, 24 April 2009 (UTC)

I agree with the above (unsigned) post. I came across documentation for Alfresco that mentioned CIFS and didn't know what it was. When I looked up "CIFS" here, it redirected me to SMB, but there was not clear section talking about CIFS and it doesn't really explain what the difference is. Reading some of the comments here I now better understand it, but it should be included in the article. I have no idea what I am talking about, so I would not be qualified to write a section on it. Would one of the above experts add a section about the similarities and differences between CIFS and SMB? If CIFS redirects here, it should be included here. --Andrew (talk) 21:49, 22 June 2009 (UTC)

I see that there is actually a page on Content Management Interoperability Services. I believe that CIFS and CMIS are closer related to each other than CIFS and SMB? (Not an expert, so I am not sure). Maybe CIFS should point to CMIS? --Andrew (talk) 16:05, 24 June 2009 (UTC)

As far as I know, the protocol named CIFS from Microsoft has absolutely nothing do do with CMIS, and I know for certain that it was SMB-derived. Guy Harris (talk) 18:06, 23 September 2009 (UTC)

I Googled CIFS as out Packeteer network monitor flagged it up as high usage. Google search took me to this Wiki SMB page. The opening statement confused me as to which is the modern parlance SMB or CIFS. If it's CIFS then why is the Wiki entry SMB. Why hasn't CIFS at least got a holding page with a brief description and then a redirection to SMB. Is the "Internets" getting short of digital space? Can the opening sentence be (at least) made more clear? — Preceding unsigned comment added by 79.121.186.28 (talk) 08:46, 26 March 2014 (UTC)

Microsoft calls it SMB these days. What other people call it doesn't count, as it's Microsoft's protocol. And they don't have separate pages for the same reason that, for example, "Mac OS X" and "OS X" don't have separate pages ("Mac OS X" is just a redirect to "OS X") and "iPhone OS" and "iOS" don't have separate pages - they're different names for the same thing. Guy Harris (talk) 18:33, 26 March 2014 (UTC)

Given Linux and probably other systems have programs called mount.cifs and smbmount WHICH ARE DIFFERENT, there is obviously some difference. Thus it would be a good idea to explain this as well as debunking any common misconceptions people have. Chris Fletcher (talk) 21:28, 20 April 2021 (UTC)

"Probably other systems"? Not true for at least some other systems. macOS, FreeBSD, NetBSD, DragonFly BSD, and Solaris all have only mount_smbfs. As far as I know, Windows has only one client IFS (installable file system) for the protocol. macOS, at least, supports current versions of SMB, so it's up-to-date.

As for Linux, an older page for the CIFS VFS says:

The CIFS VFS is a virtual file system for Linux to allow access to servers and storage appliances compliant with the SNIA CIFS Specification version 1.0 or later. Popular servers such as Samba, Windows 2000, Windows XP and many others support CIFS by default. The CIFS VFS provides some support for older servers based on the more primitive SMB (Server Message Block) protocol (you also can use the Linux file system smbfs as an alternative for accessing these).

That page points you to a page with more up-to-date information, the LinuxCIFS utils page on the Samba Wiki, which, in turn, points to the LinuxCIFS page on that Wiki, which says:

The CIFS VFS is a virtual file system for Linux to allow access to modern SMB3 servers (Windows, NetApp, EMC, Samba, Macs and Azure) as well as older servers and storage appliances compliant with the SNIA CIFS Specification version 1.0 or later. Popular older servers such as Samba 3, Windows 2000, Windows XP and many others supported CIFS by default, but modern servers and network appliances now support SMB3 or later. The CIFS VFS supports both.

On the other hand, Microsoft's MS-CIFS document says:

Specifies the Common Internet File System (CIFS) Protocol, a cross-platform, transport-independent protocol that provides a mechanism for client systems to use file and print services made available by server systems over a network.

and their MS-SMB document says:

Specifies the Server Message Block (SMB) Protocol, which defines extensions to the existing Common Internet File System (CIFS) specification that have been implemented by Microsoft since the publication of the [CIFS] specification.

so the history here, in both cases, seems to be a bit potted.

A slightly less potted history:

Originally, there was the Server Message Block protocol, which went through several revisions, adding new features for various purposes, including supporting new OSes (OS/2, Unixes, Windows NT).

In 1997, Microsoft put out an Internet Draft, draft-leach-cifs-v1-spec-00, for "A Common Internet File System (CIFS/1.0) Protocol", which said:

This document describes the file and print sharing protocol for a proposed Common Internet File System (CIFS). CIFS is intended to provide an open cross-platform mechanism for client systems to request file and print services from server systems over a network. It is based on the standard Server Message Block (SMB) protocol widely in use by personal computers and workstations running a wide variety of operating systems. An earlier version of this protocol was documented as part of the X/OPEN (now Open Group) CAE series of standards [7]; this document updates the specification to include the latest shipping versions, and is published to allow the creation of implementations that interoperate with those implementations.

I have the impression that this might have been a reaction to Brent Callaghan's WebNFS proposals from 1996, which eventually became RFC 2054 and RFC 2055. At that point, I was at NetApp as one of the members of the team doing the SMB server code in Data ONTAP.

The CIFS proposal never became an RFC, but it eventually became an SNIA standard. Neither it nor WebNFS became a Big Internet Thing.

Microsoft continued developing SMB, including items added by CIFS, such as SMB-directly-over-TCP (without the NetBIOS-over-TCP layer); the I-Ds didn't mention port 445, but that's what they eventually picked for SMB-over-TCP.

So "CIFS" is best thought of as a temporary rename of the protocol, at a time when offering LAN-oriented file sharing protocols as a general service was being considered.

The "LinuxCIFS" implementation was started, as a shinier newer SMB/CIFS client, implementing newer features, at a time when "CIFS" was the name being used. It's best to think of the two clients as "a client that implements really old stuff, for talking to really old servers" and "a client for use with servers other than really old servers". I don't know what the *BSD clients have done, but the macOS client has been dropping support for the really old servers and adding support for new protocols and servers, so they haven't kept the "really old servers" support the way the Linux kernel people have (by keeping around an old client so that support doesn't clutter the new client). Guy Harris (talk) 22:32, 20 April 2021 (UTC)