[Access to Wang masthead]

SMB Networks

The key to Unix integration
From "Special Report",  Access to Wang, June 1995
  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

If you've looked into ways to integrate Unix file and printer resources with your desktop systems, you know many possible choices are available. Most of these options require special transfer applications on the PC that do not directly integrate with PC applications. PC-based Local Area Networks (LANs) allow common resources to be shared but require effort to administer and do not integrate well with Unix.

If you'd like to take advantage of a LAN but would also like to use Unix resources, consider a Unix network server. Unix Server Message Block (SMB) network server software provides convenient access to Unix resources from PC clients without the usual network administrative effort.

Better yet, SMB server software is readily available and offers support for most PC client environments, including MS-DOS, Windows for Workgroups, OS/2, and NT.

SMB networks

SMB-compatible networks have been around for about a decade, beginning with the early IBM, 3COM and Microsoft network products. Although the SMB specification is supported by several products, it's most commonly known as LAN Manager, which was originally a server product for the early versions of OS/2. Later, LAN Manager was ported to Xenix and other forms of Unix. Mention it by name now to anyone involved with desktop systems and you'll probably get a perplexed look; as of a few years ago, a mere 2 percent of networks were using it. As a server product, LAN Manager was never able to capture a significant portion of the network market, but its influence continues in modern desktop clients through their support of the SMB protocol.

SMB networks use a simple syntax to set up shared resources and then rely on redirectors at the client end to intercept normal system calls and redirect them to the server. The SMB layer presents the image of the shared resources in the form required by the client, while the NETBIOS layer performs the actual work of interpreting the calls and transferring the data.

As can be seen in Figure 1, the SMB protocol lies between the Application and Presentation layers of the OSI model, redirecting calls for system resources to the Unix system.

SMB network support is included in a number of server forms. Unix server products are available from Digital Equipment Corp. (Pathworks) and a number of LAN Manager ports to specific Unix environments (Hewlett-Packard, SCO Unix, Data General, etc.). There is even a public-domain server - known as Samba - that can be compiled and run on nearly any version of Unix, including "free" Unix systems like Linux and FreeBSD.

Client support for SMB servers is provided ion several operating systems and user environments, including MS-DOS, Microsoft's Windows for Workgroups (with the TCP/IP add-in) and Windows NT and IBM's OS/2. The Samba package also includes a client portion, allowing a Unix system to act as a client to another SMB-capable server.

Setting up a Unix SMB network

You will need the following components in order to set up an SMB network to integrate with a Unix system:

Once the Unix server is installed, portions of the file system can be set up as shared resources through commands or using administrative software. Client PC systems can gain access to these shares and assign them to PC drive designations (e.g. F:, G:, etc.). Most PC software can be used directly with these virtual disk drives, even products not explicitly designed for network use.

To show how shared resources are set up, consider the file system tree in Figure 2. When the network is set up, the administrator defined a "share" known as PUBLIC that, in fact, represents a portion of the file system beginning at /bin/PC.software using the NET SHARE command.

At the PC, the user selects this shared resource by name and assigns a drive letter with the NET USE command. From that point forward, any eligible file located in the Unix subdirectory will also show under the user's G: drive.

Unix printers can also be shared using similar syntax. In the example, the printer known as ljmktgl to the Unix print server is set up as LASER1 and assigned to LPT2 - the value of the PC's second parallel port. (Note the PC does not have to have a corresponding physical port; this is only a logical port.)

Figure 2 also shows another interesting aspect of SMB servers: the personal drive. Normally, the only shared resources available to the client are those defined explicitly with a NET SHARE command. One exception to this is an implied file sharing resource assigned by the server, which is located at the user's Unix home directory and named the same as the user ID. In the example, user dsb, whose Unix home directory is /users/dsb, has a shared drive named DSB at that location and has assigned that resource to drive letter F:. Since the Unix home directories are usually secured so only the owner may read, write, or examine their contents, this capability effectively provides a private drive to every network user.

Accommodating differences between Unix and DOS

MS-DOS file names are much more restrictive than those used by Unix systems. How does the SMB server accommodate these differences? Unix file names are often long, mix upper- and lower-case letters, and may include additional periods and other invalid characters.

The short answer is that SMB servers show only those files that specifically fit the following MS-DOS naming limitations:

Access control and security

A similar translation occurs in mapping Unix file access permissions to DOS's limited file attributes. In instances where Unix file permissions go beyond the abilities of MS-DOS or other clients, the Unix permissions take precedence. This allows the network administrator to use directory and group permissions to control access to the Unix file system.

SMB servers support two forms of access control and security: user and share. Share security protects each shared resource with a password, which must be entered by the user each time the resource is used. The user security approach relies on the existence of a valid account for the user on the server and observes the privileges assigned to that user within the server's security system. Only one security approach can be used on a server.

For most purposes, user security works best because it enforces the same access rights present in the Unix environment, but each LAN user must be set up as a Unix user as well. Share security works better when resources are used infrequently or when there is no other need to set up users on the Unix system.

Under user security, Unix file permissions for read and write access are used to allow or deny file or directory access. Group permissions are also available, so it is possible to allow or restrict access to a shared directory through membership in Unix groups.

For example, if shared directory /bin/PC.software/winword (known to the client PC as G:\WINWORD) had read and write privileges for Unix group word and no privileges for anyone else (e.g. Unix permissions "-rw-rw----" with group - word"), only those users belonging to the word group would be able to use the application.

The use of these additional privileges is not completely transparent, however. In some instances, an MS-DOS application may become confused when the Unix file permissions conflict, such as when the user does not have write access.

In such cases, the system may show an unresolved conflict with the SHARE function or even suggest that the disk may not be formatted. These conflicts are rare, though.

Client software choices

This discussion will focus on two of several possible clients: the MS-DOS network client software offered by Microsoft and the TCP/IP option for Microsoft's Windows for Workgroups (WfWG), both free. Other SMB-capable systems-NT, OS/2, etc.-are more typically used for server purposes, not as clients.

Setting up the MS-DOS client software is straightforward, and full directions are included with the software. But be aware there are several network programs to be run when the PC network is started and this software uses a large amount of MS-DOS memory.

Unfortunately, most programs cannot be loaded into upper memory. The result: You will probably have no more than 500K of conventional memory after network components are loaded.

To use the MS-DOS client, users must log onto the network (using their Unix user IDs and passwords) and then select the resources they want by issuing net use commands. Typically, these commands are incorporated into the AUTOEXBC.BAT or other batch files so they are set up every time the computer is started.

If you would like better performance and more conventional memory, the TCP/IP add-in package for Windows for Workgroups is a better choice. This optional package adds Winsock-compatible TCP/IP support to WfWG. Note that the most recent version is a 32-bit application and requires the 32-bit add-in package-also available for free from Microsoft.

In the WfWG network approach, the user is presented with a logon screen whenever Windows is started. After logging onto the network, Windows restores connections to the shared resources last used. Additional shares can be set up from the File Manager or Control Panel as needed. MS-DOS sessions initiated within a Windows session are able to use shared drives and other resources, but there is no network support unless Windows is active.

Unix SMB networks-LAN Manager/X and its descendants can provide integrated PC/Unix support without the need for additional maintenance effort. In some cases, SMB networks can be set up for little or no cost, providing a simple, cost-effective means of getting more out of your Unix system.

Figure 1: OSI Data Model with SMB and NETBIOS Relationships

[OSI Data Model with SMB and NETBIOS Relationships]

Figure 2: Example of Unix and MS-DOS Directory Relationships

[Example of Unix and MS-DOS Directory Relationships]

Figure 3: References for SMB Server or Network Client Software

For further information on SMB server or client software, look into these resources:

  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

Copyright © 1995 Dennis S. Barnes
Reprints of this article are permitted without notification if the source of the information is clearly identified