Bugzilla – Bug 106335
cupsd cannot talk to smb printer
Last modified: 2006-04-07 09:29:37 UTC
Been trying to setup a printer which is attached to a Windows XP box on my local network. I can get through the add printer dialogs OK, but printing a test page always shows a job just sitting in the queue forever. In the cups error log I see lots of these: E [22/Aug/2005:17:49:31 -0400] [Job 1] Can not get the ticket cache for root E [22/Aug/2005:17:49:31 -0400] [Job 1] Tree connect failed E [22/Aug/2005:17:50:31 -0400] [Job 1] Unable to connect to SAMBA host, will ret ry in 60 seconds...ERROR: No ticket cache found for userid=0 It is perhaps worth noting that two other computers can print just fine. One is running Windows XP and the other is Fedora Core 4.
I don't know what the actual reason for this error message is. Please have a look at http://portal.suse.com/sdb/en/2003/11/jsmeix_print-smb-90.html (the YaST bug in the "Configuration with YaST in SUSE LINUX 9.0" section should be fixed) and http://portal.suse.com/sdb/en/2004/04/pohletz_cups_xp.html and follow the instructions and report the results.
Created attachment 47292 [details] lots of details
I just added an attachment with all the details I uncovered going through the instructions in the web pages above. Executive summary: All the SMB pieces work individually, but cups still don't print :-).
After some poking around on the web, I found that smbspool is the actual samba program used to talk to the printer. Trying it directly I get this: root@batcave> smbspool 1 tom foo 1 bar fred.txt ERROR: No ticket cache found for userid=1000 ERROR: Can not get the ticket cache for tom ERROR: Tree connect failed ERROR: Unable to connect to SAMBA host, will retry in 60 seconds... The same bugs that show up in the error log. The smbspool program does indeed appear to have all sorts of kerberos libs linked into it. This bug appears to have something to do with kerberos and smbspool.
Looking at the source for smbspool, this appears to simply be unacceptably stupid code. It has no way to get past the failure of kerberos to be active on the system so it can fall through to the code that will try to access the printer with no authorization at all (the way I *want* my printer). After examining the source, I did find that if I make my XP box *less* secure by adding a dummy user who's password can be stored in the cups printer config file over on the SUSE box, I can get printing to work (because the smbspool program tries user:password first if one is specified before it tries kerberos).
Many thanks for your detailed analysis. I reassign the bug to the maintainers of the samba-client package to which /usr/bin/smbspool belongs.
*** Bug 112755 has been marked as a duplicate of this bug. ***
Is there any way to print now, if I don't have any access to the administration of the XP box ? That's a critical point for me not to be able to print !
I'm looking into this now.
You can ignore the kerberos warnings. smbspool first tries Kerberos authentication, then username%password combinations (if they are provided within the smb-url) and then finally anonymous connections. Could you please send me a tcpdump-trace of the smbspool call ? Please take care to have the network traffic of these two commands in the trace: smbspool smb://administrator:secret@yourxp/yourqueue 1 root title 1 0 /etc/hosts and afterwards this smbspool smb://yourxp/yourqueue 1 root title 2 0 /etc/hosts thanks
Actually, the source code I was looking at tries user:password first (which is what led me to get the printer working using a new user just for printing), then kerberos, then tries to fall through to the public share code, but it never gets there. From my quick look at the code, I got the impression that the kerberos code was asking the XP box if it understood the kerberos protocol (which XP apparently answers "yes" to), but just because XP can understand it, doesn't mean there is a kerberos server anywhere on my network. So smbspool thinks it ought to use kerberos because XP can understand it and it never gets past the kerberos stuff to try the "no authentication" code. Anyway, I'll see if I can dig up tcpdump (doesn't appear to be installed by default, or at least there is nothing in my path) and get the traces.
Well, I'm attaching some "tcpdump -w <file>" runs to this bugzilla, don't know if they will help, there are lots of options to tcpdump that are gibberish to me, so if you want something different, I'll need explicit instructions about what tcpdump command to run :-).
Created attachment 47824 [details] tcpdump -w during run of smbspool with user:password auth This tcpdump file was generated while this command was successfully sending a file to the printer via: smbspool smb://printer:suse47@CLOYD/HPLaserJ 1 root title 1 @ /etc/hosts
Created attachment 47825 [details] tcpdump -w <file> from attempting to print to public shared printer This tcpdump was generated while running the following command (which fails, and says it will try again in 60 seconds): batcave:~ # smbspool smb://CLOYD/HPLaserJ 1 root title 2 @ /etc/hosts ERROR: No ticket cache found for userid=0 ERROR: Can not get the ticket cache for root ERROR: Tree connect failed ERROR: Unable to connect to SAMBA host, will retry in 60 seconds...
ok, I reproduced it here. Next time please use the "-s 0" option to create the traces. I'll post a patched smbspool-command later today. Could you please that binary ?
One other question: What exact actions did you take to allow anonymous access to your printer on a default Windows XP SP2 workstation? Which Policies did you change ?
I didn't do anything special to make the printer accessible. Just brought up the printer properties page tab for "Sharing" and checked the box that says to share the printer on the network. Perhaps if an administrator does that something magical happens behind the scenes, but just clicking the one check box is all I did. (I also told the kerio firewall I'm running that everything on my local network is trusted).
Is a pointer to the location of this patched smbspool program going to show up in this bugzilla? I wouldn't know where to look for it otherwise.
Just to a a data point that probably won't surprise anyone: I've installed beta4 now, and the printer works (or fails) exactly the same way as in beta3.
Well, I've installed RC1 now, and it is officially even worse. With RC1, I can't even use a username:password to access the printer on my XP box.
Wait! I take it back! The user:password form does work just like it has done in the previous betas - I was suffering from braincramp when I thought it was broken :-). Definitely still can't print to a public shared printer with no security though.
Just to continue the record. The 10.0-GM release also has the same problem. I can only print via user/password, not to public shared smb printer.
Can I expect this problem to be solve quickly ? I no longer use SUSE (since beta3) because of this problem. I absolutely need the ability to print on a public shared smb printer ... For the moment, I use Mandriva or Ubuntu, but I'd like to go back to SUSE ... Thanks !
An untested proposal for a workaround: Make your own backend for SMB data transfer like: --------------------------------------------------------------- #! /bin/bash # see the "CUPS Software Programmers Manual": # "Writing Filters" and "Writing Backends" # and see the man page "man backend". # debug info in /var/log/cups/error_log set -x # output "Device Discovery" information on stdout if [ "$#" -eq "0" ] then echo 'network MySmb://hostname/share "Unknown" "SMB Printer"' exit 0 fi # have the input at fd0 (stdin) in any case if [ -n "$6" ] then exec <"$6" fi # forward the data from stdin to the share if smbclient '//hostname/share' -c 'print -' -N 1>&2 then echo 'INFO:' 1>&2 exit 0 else echo 'ERROR: failed to send the data to hostname/share' 1>&2 exit 1 fi --------------------------------------------------------------- Here all is simply hardcoded in the backend, therefore replace hostname/share with the correct values for your particular case and you may have to adjust the smbclient command according to your needs. Save it as (use exactly this name): /usr/lib/cups/backend/MySmb Set read and execute permissuons accordingly (as the other backends in /usr/lib/cups/backend/). Stop and start the cupsd Verify that the new backend is listed in "lpinfo -v" Change your queue to use the new backend: lpadmin -p <QUEUE> -v MySmb
Created attachment 55194 [details] re-enable anonymous session setup with a non-zero username
Do we need to make an update for 10.0 ?
Created attachment 55202 [details] Corrected patch
If it is possible, it would be nice to have an update for 10.0. I think I'm not the only one having this problem, and few people will want to recompile smbspool. Thanks !
Update approved for 10.0: Maintenance-Tracker-2668
As we have beside this defect several minor fixes to the 3.0.20 package solved by the 3.0.20b maintenace release of Samba.org we suggest to use the same package code base for the 10.0 update as we have in the SLES 9 SP 3 tree atm.
Ok, go ahead as suggested in #31.
We need a SWAMP ID.
Discussed with Adrian: As this update was approved in comment #32 I'll create the SWAMP ID myself.
SWAMP ID is 2897.
Patchinfo written. Package submitted.
released
Perhaps there is something I'm not smart enough to do, but I ran yast update, got lots of new smb stuff including version 3.0.20b of samba-client (which includes the smbspool program). I removed the old printer definition, rebooted to make sure all the new smb programs were running, and then defined a printer from scratch, and the cups error_log shows the exact same kerberos errors I had when this bug was entered many moons ago. Do I need some magic syntax in the printer URI that the printer definition tools aren't providing? The /etc/cups/printers.conf file says smb://CLOYD/HPLaserJ (which looks like the syntax for a public share to me).
Günther: Please test with the current version available as an update for 10.0.
Please ignore the kerberos errors, smbspool just must to check if there are valid credentials around that could be reused before going down trying other authentication methods. Are you saying know that you *can* print again, or you can't ?
I'm saying I still cannot print. The job gets queued up and never goes out to the printer, I just get kerberos errors in the log. I didn't look at the patched source, but the code I looked at before in smbspool would just keep re-trying over and over again once it decided that the XP box could understand kerberos (I guess its theory was that maybe the server was temporarily down and would come back up soon or something, but there ain't no kerberos server on my network).
Created attachment 57747 [details] send own username to reach the ntlmssp session setup
This patch allows to mimic smbclient behaviour (which never does anonymous session setup, just unauthenticated ntlmssp session setups). Printing with smbspool to a freshly setup Windows XP SP1a box (having a shared printer), without domain membership or alike, was possible. Thomas, you are right, smbspool should really be much better merged with the common connect-functions from the other samba client tools.
Thomas, could you please try smbspool from this rpm ? http://www.suse.de/~gd/samba/i586/samba-client-3.0.20b-3.2.i586.rpm
Hey! It works like a charm. I didn't even install the rpm, just extracted the smbspool program and swapped it with the installed /usr/bin/smbspool, and I can now print using the same printer definition that did not work with the old smbspool.
Günther, how to go on here?
NEEDINFO -> Günther
This is fixed for SL10.1 AFAIK - good. I approve an update to the 3.020b package. Maintaince ID is: Maintenance-Tracker-3536
Andreas, should SWAMP 2668 be closed then?
ARgh - yes, close it. Sorry.
Guenther? Do you have an update?
Lars, as Guenther does not talk to me - could you please help out here? NEEDINFO gd -> lmuelle
I copied the 3.0.20b sources to /mount/work/src/done/10.0/samba/ Anything else missing?
Assigning to provide the missing patchinfo.
/mounts/work/src/done/PATCHINFO/samba.patch.box created. This patchinfo is limited by intention to the samba subpackage only. I'll assign this bug to a member of the maintenace team.