Ah yes, the things we take for granted these days.
Regardless of the OS, in order to access any file, you need a driver stack. At its highest level, the stack maintains access and status of files and their interrelationships. At the lowest levels you find the services that do data interrelationships (connecting data blocks into a file or directory) and raw data block I/O.
In the case of sharing a directory (a/k/a folder) over a network, the lower-level services that would be doing the allocation tracking and IDE/SCSI/SATA/USB I/O are replaced with network client code.
On the machine doing the sharing, a server has to be running so the client has something to talk to. Basically, this server takes the file requests and uses them to access shared files available on the server machine vis its own file system.
So to do file sharing, you need a network filesystem client driver on the client machine and a filesystem server on the target machine. And, just because people tend not to realize this, I want to emphasize that a FILE server is NOT a web server. You can have one or the other, neither or both on a machine, but the two functions are very different regardless of the fact that URLs happen to look like filesystem paths.
In Windows, the CIFS driver (originally known as SMB filesystem driver) is installed when you set up Windows Networking to work with shared files. You also get a CIFS server, which for Windows Desktop products is limited to 10 clients (Windows Server Edition lifts that limit).
The equivalent in Solaris is NFS, but the configuration model for Solaris (and for Linux) is that you have to install actual software packages for NFS client or server. NFS, however, isn't the easiest thing for a Windows client to use - unlike CIFS it's not bundled with Windows. In this case it's easier to leave Windows alone and install a CIFS server on Solaris -
i.e., Samba.
CIFS and NFS are similar but not identical services. CIFS understands the Windows file attributes (including NTFS ACL info), but not Unix file attributes (Samba has to fake it). Likewise for NFS, except that NFS is slanted towards the Unix filesystem architecture.
Samba is one of the rare cases where I considered the Windows approach as more secure than Unix. NFS in its earlier years was fairly vulnerable and the situation was made worse by the fact that it did its network port assignments dynamically. You either had to run a much looser firewall than I do or take the trouble to manually lock down the port usage.
I finally mostly switched from Samba to NFS because when doing
word processing, the auto-update function kept hitting obstacles. While the difference between a CIFS and NFS filesystem is generally transparent, this was an annoying exception.
Just for general info, Samba on Solaris isn't as full-functioned as it is on Linux. It doesn't provide the ability to mount SMB shares. Fortunately, however, there's a third-party product that fills that need.
And finally, just to fill in some history:
The original SMB file sharing was done via NETBIOS, which is a non-tcp/ip protocol. NETBIOS provided the bottom layer of the Windows file-sharing sriver stack, although you could connect in an IPX bottom-layer driver to communicate with Novell Netware servers. When Windows 95/NT 4.0 came out, TCP/IP was the transport mechanism of choice, so a bottom-layer driver for that protocol became part of the package as well. Since Windows File Sharing was now no longer based on NETBIOS Server Message Blocks (SMB), they named the new stack the Common Internet File System (CIFS).
