[Linux] Printing via CUPS to a windows box....NT_STATUS_ACCESS_DENIED
Mon, 19 Apr 2004 23:23:52 -0400
I was attempting to configure CUPS to print from my Fedora system. It
would not work. Generally, there were several problems. These problems
occurred whether I tried to configure the printer with
redhat-config-printer, which seems to use foomatic, or directly from
CUPS. I solved all the problems, but I thought I would mention them here
in case someone else is struggling with this.
Problem 1: The correct drivers had not been installed. This was actually
called properly when I tried to select the printer from
redhat-config-printer. That was fixed with
yum install hpijs
This was not a "bug", just a problem.
Problem 2: There was no lpr command. This is another situation where the
lpr command does not actually exist - you have to "choose" cups.
Running redhat-switch-printer-nox and selecting the only remaining
choice, CUPS, fixed the links - /usr/bin/lpr now symlinks to
/etc/alternatives/print, which symlinks again, to /usr/bin/lpr.cups. I
believe that this is a bug.
Finally, I had what I thought was an authority problem:
ERROR: Connection failed with error NT_STATUS_ACCESS_DENIED
ERROR: Unable to connect to SAMBA host, will retry in 60 seconds...
It turns out to be exactly the same problem that you run into when you
do mounts in from XP. For example, to use autofs to mount from XP, you
must specify a userid.
Specifying this makes the mount work - I do not have the guest user on
the xp system specified by the way. It just can't be left out.
smbspool smb://guest@MAID/GATEWAY/HPOffice a b c d e 12345
This allows the connection to work. Without the "guest@" it fails and
produces the message I pasted in above.
When you specify the printer through redhat-config-printer, there is a
place to put the userid. If you specify the printer through cups, you
specify the "url" directly, and you just use the "guest@" as above.
CUPS hides the userid. There is also a syntax to specify a password if
your network requires same. You just can't leave it blank.
Off to exercise Bugzilla, I guess. I am going to at least mention the
issue there regarding the upgrade failing to "do the right thing" with
the lpr command. The question is whether the missing password problem
should be reported to Redhat....probably yes.