4 PCShare SMB file and print services

PCShare implements a Windows 2003 SMB/CIFS compatible file and print server. The main goal of PCShare is to offer the highest compatibility for file and print services, and to support all major Windows clients as well as DOS clients with its native protocol.

The SMB/CIFS protocol is also used for named pipes where Microsoft provides additional protocols for their Exchange Server, Remote Procedure Calls, Remote Registry, etc. PCShare implements file and print services only. If PCShare should fail in a special workflow or application, please help to get the problem reproducible by documenting a simplified test case and report it to your HELIOS partner. Due to an incomplete documentation for the SMB/ CIFS protocol by Microsoft and continuously changing Windows versions via updates and upgrades, PCShare is continuously enhanced by updates and upgrades. Please ensure to verify problems against the latest version and update level.

Authentication

The PCShare server uses the HELIOS authentication server which allows local host users, NIS, LDAP and AD/PDC users. PCShare supports all required SMB/CIFS user authentication methods, including Lan Manager, NTLMv1 and NTLMv2.

TCP/IP access lists

The PCShare server supports the default HELIOS TCP/IP access lists for its services as well as a custom access list per volume to hide/show volumes for remote users.

File access security

PCShare clients run with the effective authenticated user and group permissions, which means UNIX file access permissions and user quota limits are enforced by the operating system. UNIX file and directory permissions are fully supported and can be managed in the PCShare tab of the Windows Explorer “Properties” dialog, using server host tools, from Macs connected via EtherShare or from WebShare web clients. Each PCShare TCP/IP client runs in its own process which provides higher process security in case of a protocol failure.

Inherit permissions

For new files and folders, PCShare will automatically inherit file permissions from the parent directory. For new directories, the “g+s” bit is set (if permitted). This allows quota group enforcements.

UTF-8 volumes and Unicode

PCShare requires HELIOS UTF-8 volumes which are compatible with the HELIOS EtherShare AFP server for Mac clients and HELIOS WebShare for remote web clients. PCShare supports the Unicode protocol for Windows clients allowing them to use the same file names compatible to Windows NTFS volumes. File names can have up to 255 characters and short names are supported for clients requiring it.

NTFS file streams

PCShare handles Windows NTFS file streams and related commands (create/rename/move/remove). This enables enhanced compatibility with Windows servers and NTFS as well as better cross-platform support. Windows file streams are preserved even after a Windows file is modified by an EtherShare Mac or WebShare web client. The file streams are stored in the “.rsrc” directory.

Attributes

PCShare supports the Windows file and directory attributes “System”, “Hidden”, “Archive”, “Read-only” and “Creation date”. These attributes are stored in the HELIOS resource file in the “.rsrc” directory. The attributes are stored in an EtherShare and WebShare compatible format, i.e. in a hidden file which is hidden as well for Mac or web clients.

“dt” tools

HELIOS Base includes batch tools to allow host batch compatible file management, e.g. “cp”, “mv”, “mkdir”, “rm” , “chmod”, “touch”. The “dt” tools will handle additional file information like file streams, Windows attributes, Mac resource information, and update the volume desktop database.

Desktop database

PCShare supports the HELIOS desktop database. Each volume contains a desktop database file which keeps an index of all files with associated unique file IDs.

File events

PCShare supports file events which are used by ImageServer hot folder scripts and automatic OPI layout file generation. The events are generated based on file suffixes and Mac file types. The ImageServer TCP/IP port 2002 allows clients to be notified about file changes.

User Quota limits

User quota limits are enforced. The PCShare server reports the user quota limited available disk space to its clients.

Volume backup

It is recommended to use a host based backup solution to backup PCShare volumes. A host backup solution will backup all information including file mode, owner and group. Some host backup solutions will automatically handle the resource information and additional file streams when selecting individual files. It is always safe to select complete folders for backup instead of single files, this means all related streams and attributes will automatically be archived because they are stored in the “.rsrc” subdirectory of each directory (see also the “dt” tools sync capability in the HELIOS Base manual).

A remote backup from Windows is possible but the UNIX owner, group and mode information of files and directories is not supported by the SMB/CIFS protocol and will therefore lead to default permissions in case of a restore.

Print spooling

PCShare will publish its printers via the SMB/CIFS printing protocol. Authenticated Windows clients will automatically see all published printers in the Windows Printers and Faxes list. After connecting to the shared printer queue the Windows print manager will show the print jobs. Removing jobs is only allowed by the owner or by admin users. It is recommended to use HELIOS Admin for more advanced queue management. The PCShare specified printer driver name allows Windows clients to automatically install the required printer driver if the driver name matches an installable driver within the Windows driver path. HELIOS Base provides the HELIOS printing system used by PCShare and all other HELIOS products. “lpr/lpc/lprm/lpq” compatible tools allow inspecting and modifying print jobs/queues.

Windows Terminal Server (WTS)

The WTS provides multiple sessions for different users. It connects only once to an SMB/CIFS server and multiplexes the different user sessions over a single TCP/IP connection. The same technique is used for Windows XP user switching where different user sessions can connect to the same SMB/CIFS share. PCShare has been tested with WTS and Windows XP sessions and supports the user session switching feature over a single connection. In heavy duty client environments, separate Windows clients (no WTS) have a significant performance benefit over WTS sessions where the SMB/CIFS access is being serialized by a single TCP/IP connection.

Windows oplocks

Using “oplocks”, Windows may cache the entire file until a second client accesses the same file. PCShare supports Windows oplocks, EtherShare and ImageServer will handle oplock cached files. Ensure that oplock files get flushed before accessing their data. Accessing files manually via host tools may not provide the correct data for files with oplocks. Use the “locktable” command (HELIOS Base) to list all open files and oplocks attributes.

File and record locking

Full Windows compatible file and record locking is provided by PCShare and shared with EtherShare and other HELIOS programs to permit true cross-platform file and record locking for Windows, Mac and mixed client environments. To provide fast and fully compatible file and record locking, HELIOS stores all locks in a shared memory which allows accessing locks without additional system calls. Windows and Mac require that every read or write of bytes does not interfere with existing locks. Local server file access, NFS or shared Sun storage locks are neither compatible with Windows file and record locking nor with oplocks. Therefore the same data can only be published by one active PCShare server.

Supported network clients

See a list of all PCShare supported network clients on the HELIOS website.

4.1 Server file system information

Case-sensitivity

The following table compares the behavior of the different operating systems regarding the case sensitivity.

	Preserve	Ignore
OS X (HFS default)
OS X (UFS/Xsan)		–
Mac OS 8/9
Windows
UNIX		–
MS-DOS	–

Table 4.1: Operating systems and the case-sensitivity of file names

As Table 4.1 shows, there is no case preserving under DOS, i.e. file names entered in lowercase will appear UPPERCASE in the directory listing. In contrast to UNIX, the Windows (as well as Mac) operating system is not case-sensitive when it looks for files or creates or opens them – if your application looks for “Dave”, it will also find “dave”, and you cannot create a file “Dave” and a file “dave” in the same folder in a local volume. Due to its UNIX heritage, this is not the case for HELIOS volumes.
This distinction is normally not a problem – if an application has created e.g. the file “Editor Prefs” and needs to open it again, it usually tries to open it using the same name and not “EDITOR PREFS”. If an application cannot find a file which it has created, and the file is visible under UNIX and in the Finder, it is likely that case-sensitivity is to blame. If you are able to determine the name of the file which the application is trying to open, you can often provide a workaround by using a Mac/Windows link (alias) or by renaming the file.

4.2 PCShare WINS and browsing

4.2.1 Browsing

Name resolution through WINS (Windows Internet Name Service) or broadcasts deliver the matching IP address to a given NetBIOS name, like a telephone directory inquiry returns the telephone number to a given name.

To find out which IP address represents which NetBIOS name the following procedure is applied:

Each host sends in regular intervals so called “Host Announcements” all over the network. These are received by all computers on the subnet, but ignored by all except for the LMB (Local Master Browser). From the received “Host Announcements” the LMB generates the browse list, which contains all the names known to the LMB. The browse list becomes visible e.g. in the Windows My Network Places list.

One or several BB (Backup Browser) are subordinate to the LMB for load balancing purposes. Each BB requests the browse list from its LMB in regular intervals.

Each client which would like to receive the browse list, e.g. because a user opens the Windows My Network Places list, requests it arbitrarily from any LMB or BB.

On each subnet of a domain there is an LMB and a certain number of BB and clients. Domain in this context refers to the Windows NT Domain, not to confuse with an Internet Domain.

The development of the browsing hierarchy is a dynamic process and cannot be configured. Each host which would like to become LMB, and each host which would like to obtain a browse list but – for any reasons – does not obtain one, can enforce an election. However, unlike a political “election” here every node votes for itself and does not give its vote to another. An election consists of several heats. Each host votes for itself until it recognizes that another host has cast a more important vote.

The importance of a vote depends, among other things, on the operating system version and the uptime. A host running Windows NT Server “wins” before Windows NT Workstation, and NT Workstation wins before Windows 98, etc. In case of a “tie” the larger uptime and further criteria are decisive.

After a maximum of 4 heats the “winner” of the election is found and appoints itself LMB, appoints further hosts BB, or divests existing BBs of their powers with the target of an optimal load balancing.

A browse list is complete several minutes after the election. Therefore, frequent elections have a detrimental effect and therefore should be avoided.

The LMB administers the browse list of its subnets. In order to make the hosts of other subnets visible, all other LMB browse lists must come to each LMB’s knowledge. For that purpose each LMB connects with the DMB (Domain Master Browser) and synchronizes its browse list in regular intervals with the DMB. Thus, the local browse lists are assembled to a global browse list which covers the entire domain. This process can take up to 1 hour.

The DMB is the only arrangement within the browser hierarchy which must be configured. LMBs result from elections on a subnet by broadcasts. BBs are appointed by the respective LMB. The DMB must always also be LMB on its subnets. If the DMB loses the election another host becomes LMB. This usually leads to malfunctions.

In each domain there is a PDC (Primary Domain Controller) which, among other things, administers passwords. A PDC on the network can be found by use of the Primary Domain Controller Location Protocol, a sequence of special browsing packets and name resolution.

Microsoft determined that PDC and DMB have to be the same host. Because an LMB cannot find the DMB on the network it looks for the PDC and so relies on having found the DMB. See also Browsing in 4.2.3 “Name resolution with WINS proxy”.

Thus, a Windows NT Server DMB is always also PDC. PDC functionality is not yet implemented in PCShare – the DMB functionality however is. If PCShare is to function as DMB, it must register itself with the WINS as PDC, pretending PDC functionality, in order to be considered DMB from other LMBs.

Important:: If there is another PDC on the network, the PCShare server should under no circumstances be configured as DMB or PDC!

Each WINS client must know the IP address of the WINS server, e.g. by static configuration or DHCP.

4.2.2 Name resolution with WINS

A NetBIOS name can be a group name, e.g. a Workgroup or a domain or a unique name, e.g. a computer, a service or a user. A NetBIOS name may consist of uppercase characters as well as some special characters and is restricted to max. 15 characters. If it is shorter than 15 characters it is appropriately filled with blanks. The 16th byte is a type byte, from which one can detect whether it concerns e.g. the name of a computer, of a user or of a service. Thus, each NetBIOS name is exactly 16 bytes long.

To make a computer, service, etc. on the network recognizable, it must first register itself. If another computer wants to access this name, it must do name resolution. For this to work, the IP address of the WINS server must be known. Under PCShare the WINS server address can automatically be delivered via DHCP, when configured with HELIOS Admin.

A computer registers itself via WINS by sending a Name Registration Request (unicast UDP). This datagram contains among other things the NetBIOS name and an IP address. The WINS answers with a positive Name Registration Response. This process is repeated in regular intervals (Name Refresh). If Name Refresh is not executed in the determined time interval, the WINS considers this client to have crashed or switched off, and removes its entry from the data base. Similarly a client which is switched off should log out with a Name Release Request from its WINS so that its name is immediately removed from the WINS data base and not only after a time-out. This however does not happen very often.

The WINS will reject a registration (negative Name Registration Response), e.g. if a client wants to register a name which another client has already registered successfully before. This leads then to an (possibly quite strange) error message at the unsuccessful PC.

A client, which needs to get a name resolved, sends a Name Query Request (unicast UDP) to the WINS. The WINS answers with a positive Name Query Response, which contains the IP address of the looked-up NetBIOS name or with a negative response, i.e. the looked-up name is not known to the WINS (anymore).

If name resolution with WINS fails the client still tries it with some Name Query Requests which are sent as broadcasts. If the looked-up NetBIOS name is located on the same subnet its carrier will answer with a unicast Name Query Response.

If this still fails DNS (Domain Name System) can be used.

In a larger network several WINS may share the tasks, e.g. for reasons of reliability or for load balancing purposes. These WINSs do replicate in regular intervals their data bases among themselves, in order to always share the same level of knowledge.

Note:: A replication from WINS is not implemented in PCShare at present, because Microsoft keeps the required “WINS Replication Protocol” secret. PCShare can be employed as exclusive WINS only.

4.2.3 Name resolution with WINS proxy

If the WINS is not known to PCs which are located on a subnet they can only use broadcasts for name resolution. In this case a WINS Proxy can be used as a link.

The IP address of the WINS must be known to the WINS Proxy. It listens on its subnet for broadcasts and forwards these to the WINS. It incorporates a local cache in order to hold network traffic within limits. Thus, the nodes on the broadcast subnet can also resolve names of computers or services which are on other subnets. However, this does not work the other way round.

The WINS Proxy should only be used for a transition period, until all nodes on the subnet are correctly configured and communicate directly with the WINS.

The communication with the WINS Proxy puts unnecessary workload on the network and can also cause additional problems. If a node gets more than one response after a broadcast it regards this as an error, even if the responses are correct and consistent, and rejects the received responses.

Nodes which do not communicate with the WINS broadcast their existence in regular intervals on their subnet. The WINS Proxy can then forward these broadcasts to the WINS. However, this does not lead to a registration of the broadcast node with the WINS, it is merely checked whether a broadcast node carries a name which a WINS client had already registered. If necessary, the WINS Proxy refuses the broadcast node registration.

HELIOS Admin allows making adjustments which influence he behavior of PCShare. Here, we discuss issues which affect name resolution and browsing.

IP access

For safety reasons it can be necessary to forbid computers with certain IP addresses to access the PCShare server. However, this option should only be used with caution because the structure of the browser hierarchy is a dynamic process, and therefore it is often not predictable which host will take which position in this hierarchy.

If any host requests a browse list but is prevented by the IP access list from doing so, this may lead to a new election. For this, it is irrelevant whether a user opened the Network Neighborhood list, it came by periodic testing of the browse list or the rejected host is located on the same or another subnet.

Note:: An inappropriately selected entry in the IP access list leads constantly to new elections. In this case you will be unable to get a stable and reliable browser hierarchy.

Browsing

PCShare needs a NetBIOS host name as well as a NetBIOS domain name. If not configured in a different way, the host name is the PCShare server name, and the workgroup name is “WORKGROUP”:

PCShare will force – shortly after booting up – an election and try to become LMB. This behavior can also be turned off:

Microsoft did not define a mechanism which allows to find the DMB on the network. Instead, there is a mechanism (Primary Domain Controller Location Protocol) to find the PDC on the network. Hence PCs rely on the fact that they will thereby also find the DMB. On that score PCShare must pretend PDC behavior (i.e. respond to this PDC Location Protocol).

But this is just a fake behavior since full PDC functionality is not implemented in PCShare:

WINS

By default, PCShare is a WINS server, which is used on a PC network to map names to IP addresses. It can provide name, TCP/IP address, etc. when asked by Windows clients. If it is not the WINS server itself, PCShare must know where to register itself and which arrangement is responsible for name resolution. WINS should only be switched on if PCShare is the only WINS server on the network.

PCShare can also function as WINS Proxy. In case of doubt, WINS Proxy should remain switched off. Only if WINS Proxy is configured the Proxy Registration Check checkbox is available. This helps to avoid duplicate computer names. Duplicate computer names in one network will not work reliably.

The Scope Identifier is a means to divide the flat NetBIOS name space into sections, when NetBIOS over TCP/IP is used. An hierarchy as in the DNS name space is however not realized. It defines a group of computers that recognize a registered NetBIOS name. Computers with the same Scope ID will be able to recognize each other’s NetBIOS traffic or messages.

4.2.4 Querying PCShare for WINS & Configuration information

With socket <ipaddress> 2003 or socket <hostname> 2003 a connection to the master PCShare process can be established and “Name Binding Service” configuration & status can be queried. The following short abstract shows how certain information can be listed.

Note:: In a complex network you may have to wait several minutes after starting PCShare before a stable browsing hierarchy has been reached.

: Issue the command socket localhost 2003, type help for the command overview and quit to leave.

Note:: By default, the PCShare service port can only be reached from localhost. See RemoteAccess in 7.1 “PCShare preferences”.

After entering status the master PCShare server will respond with a status line which lists the PCShare version incl. update level, start date and uptime of the PCShare master process as well preference settings.

[PCShare server info: status]
  'PCShare 6.0.0' pid:26517, running: 0m 13s, started Fri Nov  7
  15:19:06 2014
Preferences:
  dirs:16384  files:8192  clientFiles:4096  fileCache:4096
  searches:128
  Unicode Oplocks StreamLocks
forked child processes since start:0
no current child processes

Use help to list available commands:

quit: Terminate session.
status: Shows the master process status.
childs: Shows current child/client processes.
if: With if the configured TCP/IP interfaces are listed with TCP, broadcast and MAC address. If the interface is registered for PCShare the column “reg” lists “+”, otherwise “-”.
wins: With wins information about WINS will be listed as stored in “HELIOSDIR/var/run/wins.db”, for example name and addresses, expiration date as well as type and state. In case the PCShare server is not WINS itself, this will return “No WINS entries”.
winsproxy: With winsproxy information about WINS proxy will be listed, see wins. In case the PCShare server itself is not WINS or there is no WINS proxy information, this will return “No Proxy WINS entries”.
winscl: With winscl current connection information about WINS will be listed, e.g. NetBIOS name, type and flags.
winstime: With winstime information about WINS will be listed ordered by time. See wins.
brconfig: With brconfig configuration information about the PCShare server is listed. Apart from host name, domain name and comment which are always listed, any changes to the default parameter settings are listed also. For example, if the PCShare server is not WINS.
browse: With browse all known browsing information is listed, e.g. domains, hosts, LMB & BB.

4.3 Print to Windows workstation printers via SMB

4.3.1 smbif

“smbif” is the interface program for printers that are connected to the print server through SMB. It is used for all printers (including PostScript printers and imagesetters). “smbif” forms the link between the HELIOS LPR and Windows printers.

Print jobs received by the print server from a workstation on the network are processed and queued before being sent to the SMB printer through the network again.

Due to print job spooling, it is more efficient to drive Windows printers through the print server, rather than accessing them directly from the workstations. We recommend that you select an appropriate name for the queue which shows which printer it drives and also indicates that it is a queue and not the printer itself. For example, add “spooler” to the queue’s name. See 3.5 “Windows printer output settings”.

4.4 Print server utility programs

4.4.1 pcfilter

The “pcfilter” program, which was designed to be used by the PCShare print spooler, can be used to carry out print job filtering and character set translation operations which are commonly required for different types of ASCII-printers.

Usage:

pcfilter <printer_name>

“pcfilter” is called on/from UNIX with command line options.

`[-d]`	Filter out “Ctrl-D” in PS
`[-f]`	Add “form feed” to last page
`[-c crmapping]`	Map 'cr' to 'crlf', 'lf' or 'lfcr'
`[-l lfmapping]`	Map 'lf' to 'crlf', 'cr' or 'lfcr'
`[-I initsequence]`	Byte sequence at start of job
`[-E exitsequence]`	Byte sequence at end of job
`[-i inputcharset]`	Input character set …
`[-o outputcharset]`	… maps to output character set

For example, to automatically add a “form feed” character to the last page of each print job, the -f option must be specified:

$ pcfilter -f

“pcfilter” can also be called with the name of an exported printer. It references an option list for the particular printer in the “Preferences” file. In the following example a “form feed” flag for the printer “ljet” is set:

# prefvalue -k 'Printers/ljet/pcfilter/formfeed' -t bool TRUE

Appropriate entries in the “Preferences” file are made automatically when you export printers via HELIOS Admin. To choose print job filtering or character set translation use PCShare Admin. This is much easier than doing it manually (see 7.2 ““pcfilter” preferences”).

The “pcfilter” options in “Preferences” are:

formfeed: Add FF character to last page of job
ctrld: Filter Ctrl-D characters from job and prefix each job with “%!PS”
cr (=crlf): Convert CR characters to CRLF
cr (=none): Strip CR characters
lf (=crlf): Convert LF characters to CRLF
lf (=none): Strip LF characters
init (=<string>): Specify initialization string
exit (=<string>): Specify exit string
input (=<name>): File name of input character mapping table (optional)
output (=<name>): File name of output character mapping table (optional)
postscript: Resolves PostScript jobs

If specified, the parameters input=name and output=name must always be specified as a pair.

init and exit string are both limited to 1000 bytes in length.

PCShare has the following character mapping tables in “HELIOSDIR/var/cmaps” for use by “pcfilter”:

iso7, iso8, pc, mac, ebcdic, epson, fx1050ibm, fx850ibm, hp

The ISO7 table only maps characters from hex. 00-7f. All other tables map all characters from hex. 00-ff.

The Epson and EBCDIC tables are provided as examples only. The Epson table is compatible with the FX10-50 and FX80-50 printers and the EBCDIC table only maps the valid EBCDIC codes.

Note:: If your print job contains character codes which are not specified (i.e. missing) in the chosen input table, these codes are ignored and an error message is issued to the system message file. A maximum of 10 such messages are written per print job.
If your print job contains character codes which are not specified in the chosen output table, these codes are ignored and not passed to the printer.

The tables are specially compiled binary mapping files which can only be edited using PCShare Admin.

You can also specify “pcfilter” for a local Windows printer which is configured to receive print jobs from a UNIX spool queue. Here is an example from the “Preferences” file:

[][Printers][epson-1][pcfilter][formfeed] 
flags=0 
type=Boolean 
value=TRUE 
[][Printers][epson-1][pcfilter][ctrld] 
flags=0 
type=Boolean 
value=FALSE 
[][Printers][epson-1][pcfilter][postscript] 
flags=0
type=Boolean 
value=FALSE 
[][Printers][epson-1][pcfilter][exit] 
flags=0 
type=String 
value=[4] 
\007 
[][Printers][epson-1][pcfilter][input] 
flags=0 
type=String 
value=[4] 
iso8 
[][Printers][epson-1][pcfilter][output] 
flags=0 
type=String 
value=[2] 
pc

pcfilter and Windows PostScript jobs

“pcfilter” can also be used to correct several PC-specific problems which can occur when printing to a PostScript printer which is connected to the host via a network.

Particularly when printing PostScript from Microsoft Windows, a “Ctrl-D” character is often included with the print job data to indicate end-of-job to the printer.

If you are using a PostScript printer with a network connection, it is necessary to filter out the “Ctrl-D” since it will cause a printer error. This is because it is the responsibility of the print server and not of the application program to signal end-of-job in a way appropriate to the chosen hardware interface (RS-232, Ethernet, etc.).

Furthermore, some PostScript printers expect the character string “%!PS” at the very beginning of each PostScript print job. If this string is missing it is assumed that the file is plain text, which is then automatically converted to PostScript before printing, resulting in the printout of a PostScript program listing rather than the print job itself.

If you are using a PostScript printer connected to the host, you can filter out “Ctrl-D” characters and add “%!PS” to the start of each print job, by specifying PCShare’s “pcfilter” utility in the UNIX print command.

An appropriate print command is created automatically when you configure printers with PCShare Admin and choose a PostScript character mapping table. See also the description of the magic preference in the HELIOS Base manual for related information.

Note:: When printing to an “lpr” printer queue, make sure that you switch off the Send Ctrl+D Before Each Job and Send Ctrl+D After Each Job checkboxes in the Windows printers preferences. Network printers do not understand “Ctrl-D” characters.

Each PCShare SMB/CIFS queue contains the “pcfilter” program in its export specifications. This is automatically set by the HELIOS Admin SMB/CIFS printer publishing setup (Windows tab in the printer settings dialog).

HELIOS Manuals September 10, 2020