7.9. Disabling Point and Print
Under some circumstances, an administrator may wish to disable support for driver downloads and instead require that Windows clients install a driver locally when connecting to the Samba print share. This type of setup is not recommended, because it forces Samba to act in ways not normally supported by a Windows print server and hence not normally tested by Windows clients.
The p-n-p architecture rests on two supporting layers. Windows NT-based clients require that the print server support printing calls based on Microsoft Remote Procedure Call, or MS-RPC (often referred to by the named pipe over which they are implemented, spoolss). To disable Samba's support for the printing RPC operations without affecting the other RPC based features in Samba, such as domain membership or domain controlling, set disable spoolss = yes in the [global] section of smb.conf. This removes the Printers and Faxes icon from the clients' folders when they browse the server. The default value for this parameter is no, which means that smbd should support RPC-based printing.
Disabling spoolss support in Samba bas been known to cause Windows NT-based clients to continually poll the server for printer status updates, which results in high CPU usage by the associated smbd processes. Disabling spoolss support should be done only for very specific needs and only if you are willing to deal with the consequences.
Windows 95/98/Me clients use an older printing protocol referred to as LanMan printing. Therefore, disabling RPC-based printing has no affect on these clients.
Support for the spoolss set of RPC's is a global configuration option. Sometimes it is desirable to support p-n-p for the majority of printers on a Samba host, but allow clients to install a driver locally for a few specific print queues. This is a common need when the driver just doesn't work with a Samba print server.
This is one of those cases where forcing a Windows client into an untested use pattern can cause strange results. When a user connects to the driverless print queue, the client asks her to install a driver locally, as we have already seen. After doing so, the client creates a local printer object rather than a printer connection. Windows then frequently attempts to open the print queue on the server with administrative access that matches what it would expect for access to the local printer object. Of course, just because someone is a local administrator of their machine does not necessarily equate to root on a Unix print server. Samba (correctly) denies the request for excessive rights to the printer and the client will then display an error to the user that states, "Access denied; Unable to connect."
This is a very confusing error for the user, because she is still able to send documents to the printer without difficulty. The service option use client driver is designed to work around this cosmetic defect on the client. Enabling this parameter for a print share instructs Samba to map all requests for administrative access to standard print access. The result is that the client's original request succeeds. It never encounters the "Access denied" error from the server and hence never displays the confusing error message to the user.
It is important to remember that neither of these options should be enabled if the print queue is configured to support p-n-p for clients.