[Samba] Problems with SPOOLSS WinNT driver uploads

Tim Allen timallen at ls83.fsnet.co.uk
Sat Aug 3 11:45:02 GMT 2002


After a week of concerted experimentation with the spoolss driver uploads,
We've also come to the conclusion that if at all practical, it's a whole lot
easier to just install the drivers on the clients.

Drivers seem to be split into the following categories:

1. Drivers that won't install onto a local client, NT server, Samba server.
There's something fundamentally broke with these.

2. Drivers which install locally or onto a NT server, but won't install onto
a Samba server, or give strange results on a Samba server.

3. Drivers which install onto NT server and Samba with no problem.

All my experience is with HP drivers, different ones of which fall into all
the above categories. All tests with Samba 2.2.5 with Jerry's patches.

2 is obviously the interesting case, as it indicates differences between
Samba and NT4 servers. A particular issue that we had was with an HP driver,
originally installed on an NT server and working without problems with NT
and W2k clients. This driver would upload without problems to a Samba
server, and function correctly with NT4 clients. However, with W2k clients,
applications which tried to change the devmode settings did not work
correctly.

My guess is that a lot of the problems are down to permissions, and W2k has
such a plethora of these that the chances of failure are just increased.

Some things to check:

If you are unable to upload drivers, check that you do actually have local
administrative rights. Check the domain admin group setting in smb.conf.

Delete any "stale" drivers from the clients.

Rename printer shares in smb.conf. If it's finally time to give up on
uploading a printer driver, set "show add printer wizard" = No and "use
client driver" = yes. However, if the printer share names are left
unchanged, clients are prone to not request a local install of the driver
but use whatever has previously been downloaded. To force clean local
downloads of drivers, rename the print shares.

We've ended up with a pair of Samba servers, one supporting spoolss with
co-operative drivers, the other running with client drivers for the SOB's.


Tim Allen


Steve Thom wrote:

I encountered the same issue. A quick look on Google showed that this is
not
unique to Linux either. There is a patch, but it didn't make much
difference.

After fighting is a few days I gave up and set "disable spoolss" to "yes",
and "show add printer wizard" to "no" in the global section. I then deleted
the print$ share, and placed the 9x, NT/2000 and XP drivers in a read-only
share that everyone could access (even guest and bad user).

I commonly do this in 30 client environments. I usually need to visit every
desk anyway, so now I have to install the print drivers manually. Hopefully
this will be solved someday, I don't believe it is a Samba issue per se.
Jerry may want to elaborate on the issue...

One benefit - one 2000/XP/NT user can't hose the printer properties for the
other 2000/XP/NT users (like they can in 2000 server). Everyone has his or
her own drivers, which makes troubleshooting bad print drivers a bit
easier.

I know this isn't the answer you were looking for, but it really made my
life easier. I now have no fear of deploying a linux/samba server. Fewer
problems all around.

Steve











More information about the samba mailing list