Bug 80717 - Printing to smb share hangs
Printing to smb share hangs
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-printer (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
David Lawrence
Depends On:
Blocks: 79579 CambridgeTarget
  Show dependency treegraph
Reported: 2002-12-30 08:09 EST by Hans de Goede
Modified: 2014-08-31 19:24 EDT (History)
3 users (show)

See Also:
Fixed In Version: 0.6.73-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-09-09 04:03:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output of printconf-tui --Xexport (2.98 KB, text/plain)
2003-01-02 07:50 EST, Hans de Goede
no flags Details
output of strace -p (3.93 KB, text/plain)
2003-01-08 15:29 EST, Hans de Goede
no flags Details
output of strace -p -s 100 (4.49 KB, text/plain)
2003-01-11 11:39 EST, Hans de Goede
no flags Details

  None (edit)
Description Hans de Goede 2002-12-30 08:09:15 EST
Description of problem:

Printing to an smb share on a win9x machine hangs, lpq says active, ps aux shows
lotts of processes related to printing but nothing happens, and this continues
for atleast 5 minutes.

This is with a clean phoebe install (thus using cups)
Comment 1 Tim Waugh 2003-01-01 07:35:48 EST
_Any_ SMB share printing hangs to this machine, or is there some particular
set-up that makes this hang?  For example, what kind of security is there on the
share, and what workgroup etc settings are there?

What would be really great is the output of printconf-tui --Xexport (don't
forget to * out any passwords in it before attaching..).
Comment 2 Hans de Goede 2003-01-02 07:48:38 EST
I've tried printing to the said win9x machine with the printer configured with
either the cdj550 or the hpijs driver. No difference.

Printing text or postscript makes no difference, exept that with postscript in
the ps aux output ghostscript is there and with txt not.

Printing a txt file with smbclient from the commandline works.
Please note that the username aap in the configfile is bogus, this is with share
level access control but printconf-gui didn't lett me add a share without an

I have the feeling the :"smb://aap:neeltje/neeltje/apollo 7 hans aap 1 cpi=12
lpi=7 page-bottom=36 page-left=36 page-right=36 page"

process in a ps auxw output is hanging.
Comment 3 Hans de Goede 2003-01-02 07:50:01 EST
Created attachment 89051 [details]
output of printconf-tui --Xexport
Comment 4 Tim Waugh 2003-01-03 07:25:23 EST
I expect it's because of the bogus user name.  redhat-config-printer-0.6.27-1
fixes the bug that prevented you from entering no user name.  Please try that
(and of course take the user name out).  Thanks.
Comment 5 giulioo 2003-01-06 15:05:58 EST
FYI, if a share is password protected, win9x completely ignores any username you
use in
smbclient .. -U<dummy_username>%<real_pass>
and let you in as long as real_pass is ok.
Comment 6 Tim Waugh 2003-01-06 15:58:13 EST
What does this say?:

smbclient //neelje/apollo password -N -P -c quit
Comment 7 Hans de Goede 2003-01-08 06:58:51 EST
Ah that one does the trick (shows us (me?) howto solve the problem) :

[hans@shalem hans]$ smbclient //neelje/apollo neeltje -N -P -c quit
added interface ip= bcast= nmask=
error connecting to (Connection refused)
Error connecting to (Connection refused)
Connection to neelje failed
[hans@shalem hans]$ cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.               localhost.localdomain localhost             gw.highrise.nl gw             neeltje.highrise.nl neeltje             shalem.highrise.nl shalem           gollum.highrise.nl gollum
[hans@shalem hans]$ nslookup neeltje
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.

Name:   neeltje.highrise.nl

[hans@shalem hans]$ cat /etc/resolv.conf
search highrise.nl


So what happens is that smbclient uses DNS to lookup neeltje and finds an old
dns entry (my lan used to have real ip's but has been renumbered to 192.168.1.x
since then, but the externally hosted dns was never updated to reflect this)

This used to work just fine since I always fixed this problem by adding my local
machines to /etc/hosts for some reason smbclient with the options you provided
bypasses /etc/hosts.

So there is the problem. I see 2 fixes:
1-you lett the smbprinting honor /etc/hosts
2-I cleanup my DNS so that it doesn't report invalid IP's

I think both should be applied, since other smb setups might depend on
/etc/hosts too.

Comment 8 Hans de Goede 2003-01-08 06:59:58 EST
One additonal remark, still this shouldn't cause the printjob to hang, but
should just fail.
Comment 9 Tim Waugh 2003-01-08 07:49:54 EST
The smb.conf name resolve order option should be used, or else your /etc/hosts
file should be fixed.

Also, a refused connection might be a transient error, so I think it is correct
to keep trying.  I imagine (but don't know for sure) that it will eventually
give up.
Comment 10 Hans de Goede 2003-01-08 10:59:00 EST

I just found out that there's a typo in the smbclient cmdline you gave above and
I tried. Its trying todo stuff to neelje instead of neeltje note the missing t.
With the t in place "smbclient //neeltje/apollo password -N -P -c quit" says:

[hans@shalem hans]$ smbclient //neeltje/apollo neeltje -N -P -c quit
added interface ip= bcast= nmask=

I thought maybe one of the additonal params you specified caused /etc/hosts to
be ignored, but that wasn't the problem. So we're back where we started,
printing hangs. This kinda figures since I've tried printing a txt file with
smbclient before and that worked (See above).
Comment 11 Tim Waugh 2003-01-08 11:13:55 EST
[hans@shalem hans]$ smbclient //neeltje/apollo neeltje -N -P -c quit
added interface ip= bcast= nmask=

..and you got a prompt after that, right?  So it worked.

Have you tried a newer redhat-config-printer yet?
Comment 12 Hans de Goede 2003-01-08 12:00:10 EST
Just tried redhat-config-printer-0.6.29-1 removed the printer applied,
reinstalled it, printing still hangs

But I can confirm an empty username is ok now.
Comment 13 Tim Waugh 2003-01-08 12:07:35 EST
Okay, let's start prodding the backend process then.  Does 'strace -p ...' or
'gdb /usr/lib/cups/backend/smb ...' reveal anything interesting about what it's
up to?
Comment 14 Hans de Goede 2003-01-08 15:29:37 EST
Created attachment 89218 [details]
output of strace -p

Here's a log of strace -p, it seems to try to connect, get some strange error
and then wait 60 seconds. It does connect to the right IP, so the /etc/hosts
thingy most defenitly isn't the problem.

Looking more closely at the trace it seems the smb backend does something
different then smbclient does and that it is an smb protocol problem. easiest
fix is maybe to switch back to just calling smbclient from a wrapper script.

Otherwise it is probably best if you reproduce my situation here at home at RH.
Comment 15 Tim Waugh 2003-01-08 15:41:07 EST
Please add '-s 100' to the strace command line so that we can see what the error
says.  Thanks.
Comment 16 Hans de Goede 2003-01-11 11:39:13 EST
Created attachment 89304 [details]
output of strace -p -s 100

That -s 100 does the trick, it says the password is invalid, this isn't true,
but it does makes some sense. I've had a simular problem at work printing from
windows 2000 to an win98 machine, for some reason it only works when I set an
empty password, and this is m$ to m$, 98 running share level access. The
machine giving the problems here at home is a win95 (I think osr2).

My theory:
-the smb backend of cups tries to use an encrypted password and doesn't retry
with an unencrypted passwd, win95 still uses unencrypted passwords.

Note that this used to work just fine in 8.0 so people upgrading and switching
to cups will be unpleasently surprised.

Note: Smbclient appearently tries both encrypted and unencrypted password, or
somehow just knows which to use when.
Comment 17 Hans de Goede 2003-01-11 11:47:58 EST
Just tried setting the win95 share to an empty password, updated printconf
accordingly, and it works. So I really think its the password encryption thingy.

2 last remarks:
-still it shouldn't hang, a bad password is not something which will go away by 
-I can live with an empty password, but this is probably going to bite other
Comment 18 Tim Waugh 2003-01-11 12:43:40 EST
Well, /usr/lib/cups/backend/smb is just a symlink to /usr/bin/smbspool, which is
from samba-client.

So if it's an SMB backend problem (of not trying unencrypted passwords when it
should), it's in the samba package.
Comment 19 Jay Fenlason 2003-03-06 15:15:32 EST
redhat-config-printer is setting an incorrect PrinterURI in
It should say
PrinterURI smb://username:password@workgroup/server/printer
Instead, the line reads
PrinterURI smb://username:password/server/printer
If I edit the file with either cupsconfig or by hand, printing works.

(Well, I also have to tell CUPS that it's a text-only printer that does not
understand postscript.  Despite enabling "text-only printer" in
redhat-config-printer, it insisted on sending postscript to it.)
Comment 20 Tim Waugh 2003-03-06 16:34:02 EST
The workgroup in this case is not known to redhat-config-printer (see the
'printconf-tui --Xexport' attachment).

Hans: if you fill in the 'workgroup' field in using the config tool, does that
fix the problem?
Comment 21 Tim Waugh 2003-07-31 04:43:00 EDT
Comment 22 Hans de Goede 2003-08-03 10:46:42 EDT
Yeah I'm still here, I just had other priorities :) I'll try both scenarios
(with and without a workgroup se)t with severn this week.

Comment 23 Hans de Goede 2003-08-04 11:35:26 EDT
As promised I've tried both scenarios:

With severn and without a workgroup the problem is still there.
With severn and with a workgroup everything works ok.

So yes the problem goes away once a workgroup is entered, but when you use
smb-tools from the cmdline you don't need to enter a workgroup and it _still_
works. Also under windows itself when you enter a share name you usually don't
include the workgroup, so I think it should work even without a workgroup, but
thats up to you.
Comment 24 Tim Waugh 2003-08-14 05:55:16 EDT
Jay: Any idea why the smbclient command line can work even with the workgroup
omitted, but the smbspool command requires it?  This seems to be something that
smbclient can work out but smbspool can't.
Comment 25 Hans de Goede 2003-08-14 06:36:36 EDT
I don't think smbspool needing a workgroup is the problem, as said above if I
also ommit the password (and tell the win95 machine there is no password)
everythi9ng works ok. The problem is that the URL with a password but without a
workgroup isn't recognised. This could mean 2 things:
1 it isn't possible te create a valid smbspool URL with a password and without a
2 printconf doesn't know howot generate a correct URL with a password and
without a workgroup

My bet is on 2 :)
Comment 26 Tim Waugh 2003-08-29 08:47:48 EDT
Well, the URI it is generating is this:


If that's wrong, I need to know what the correct one is.  As Jay said above:

> redhat-config-printer is setting an incorrect PrinterURI in
> /etc/cups/printers.config
> It should say
> PrinterURI smb://username:password@workgroup/server/printer
> Instead, the line reads
> PrinterURI smb://username:password/server/printer

..but I don't *have* the workgroup unless the user tells me it.

Jay, do you have any insight to offer here?
Comment 27 Hans de Goede 2003-08-29 13:16:28 EDT
From "man smbspool":

       · smb://server/printer

       · smb://workgroup/server/printer

       · smb://username:password@server/printer

       · smb://username:password@workgroup/server/printer

So the correct URI without a workgroup is:
Comment 28 Tim Waugh 2003-08-29 13:41:24 EDT
Aha.  Hopefully 0.6.73-1 contains the fix.
Comment 29 Tim Waugh 2003-09-08 05:06:18 EDT
Please let me know if it works for you.  Thanks.
Comment 30 Hans de Goede 2003-09-09 04:03:41 EDT
Works like a charm!
Comment 31 Tim Waugh 2003-09-17 04:56:08 EDT
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.