Description of problem: Today I have noticed that printing via my smb printer ceased to work. Any attempt to print anything using evince, firefox or gedit results in a pop-up window saying “Too many failed attempts”, and the following lines get written to /var/log/cups/error_log: I [13/May/2009:21:55:20 +0200] [Job ???] Request file type is application/postscript. E [13/May/2009:21:55:20 +0200] Print-Job: Unauthorized On the other hand, it is possible to print test pages using system-config-printer, or to print with openoffice: I [13/May/2009:22:12:21 +0200] [Job ???] Request file type is application/postscript. E [13/May/2009:22:12:21 +0200] Print-Job: Unauthorized I [13/May/2009:22:12:21 +0200] [Job ???] Request file type is application/postscript. I [13/May/2009:22:12:21 +0200] [Job 122] Adding start banner page "none". I [13/May/2009:22:12:21 +0200] Saving subscriptions.conf... I [13/May/2009:22:12:21 +0200] [Job 122] Adding end banner page "none". I [13/May/2009:22:12:21 +0200] [Job 122] File of type application/postscript queued by "jsikorski". I [13/May/2009:22:12:21 +0200] [Job 122] Queued on "hp" by "jsikorski". I [13/May/2009:22:12:21 +0200] Saving subscriptions.conf... I [13/May/2009:22:12:21 +0200] [Job 122] Started filter /usr/lib/cups/filter/pstops (PID 3535) I [13/May/2009:22:12:21 +0200] [Job 122] Started filter /usr/lib/cups/filter/foomatic-rip (PID 3536) I [13/May/2009:22:12:21 +0200] [Job 122] Started backend /usr/lib/cups/backend/smb (PID 3537) I [13/May/2009:22:12:21 +0200] Saving subscriptions.conf... I [13/May/2009:22:12:23 +0200] [Job 122] Completed successfully. I [13/May/2009:22:12:23 +0200] Saving subscriptions.conf... I [13/May/2009:22:12:23 +0200] Saving subscriptions.conf... There are some errors still present, but it works. Printing with apps currently broken did work a while ago, and I did not touch anything in the configuration. The printer is connected to a PC running under Windows XP Professional SP3. Commenting out AuthInfoRequired username,password in /etc/cups/printers.conf and restarting cups allows to work this problem around. Version-Release number of selected component (if applicable): cups-1:1.3.10-5.fc10.x86_64 How reproducible: always Steps to Reproduce: 1. Add a smb shared printer 2. Start gedit 3. Try to print Actual results: “Too many failed attempts” window pops up, no printing Expected results: Printing works as it used to Additional info: Please let me know if there is any additional information I could provide.
Changing component to gtk2, as the GTK+ print dialog needs to present an authentication dialog in this circumstance. (mkasik, any progress on that?)
The interesting thing is that an authentication dialog was never necessary, nor is it presented when printing in openoffice.
Also, obviously no authentication is required on the printer side since printing works with the config file change mentioned above.
Mareks authentication patch is in the gtk2 package in F11.
Could you add it to gtk2 in F10 as well then, please?
(In reply to comment #2) > The interesting thing is that an authentication dialog was never necessary, nor > is it presented when printing in openoffice. "Was never necessary" meaning in previous Fedora versions, where the username and password had to be stored as part of the queue's device URI? Or do you mean something else?
Samba authentication is not supported in the patch yet. Marek
Marek, this isn't specific to samba. It's about presenting an authentication dialog when the queue you are about to submit a job to has an auth-info-required attribute. Let me outline in again, because I don't think I've done so outside of private mail: The situation here is that the CUPS backend has previously signalled that it requires authentication information in order to send a job to the destination. For instance, the 'smb' backend might set the auth-info-required attribute to ['username','password'], for a device URI of smb://server/share with no "username:password@" part in the URI. In this case, system-config-printer-applet will notice that the job has stopped and requires authentication, and ask the user for it. It will then attempt to restart the job, providing the correct auth-info attribute. However, if the job is still waiting for authentication (the user may not even be logged in when their job gets to the front of the queue), CUPS will require IPP authentication for any additional jobs submitted for that printer submitted, and it expects this authentication to be supplied in the 'auth-info' attribute. In other words, the first job submitted to such a queue will be accepted by CUPS, but (presuming no authentication is performed in the mean-time) subsequent jobs will require authentication at job submission time. CUPS will allow 'normal' IPP authentication for this, such as HTTP "Basic", but of course the job will still require the correct authentication information for (e.g.) the SMB server. It's just that it will try those credentials first (and probably fail). We want to avoid this because a user may submit a job to a busy queue, go home, and come back next day to find they they need to provide authentication details to re-join the queue. So, if GTK+ can spot an 'auth-info-required' attribute for the printer it is about to submit a job to it should attempt to discover the correct information (either from gnome-keyring or a user dialog) and submit that in an 'auth-info' attribute along with the Print-Job request. By doing this, it can avoid CUPS asking for authentication at that step. FWIW, system-config-printer 1.1 uses gnome-keyring to store authentication credentials (with user opt-in), so perhaps there is scope for the print dialog to look for that and use it.
(In reply to comment #6) > (In reply to comment #2) > > The interesting thing is that an authentication dialog was never necessary, nor > > is it presented when printing in openoffice. > > "Was never necessary" meaning in previous Fedora versions, where the username > and password had to be stored as part of the queue's device URI? Or do you > mean something else? I have a document here printed back in February, so I'm 99 % sure it used to work in F10. I also do not remember touching the config (there was no reason for it). Is it possible that the offending line got added to /etc/cups/printers.conf automatically?
What is more, the date in the config file says 20090414 14:18. So it seems that it was updated automatically. The question is, what triggerred the update then.
Julian: you may well have been able to print one document previously, even when authentication information is not present in the queue's device URI -- you would have been prompted for it by system-config-printer-applet -- but after that time CUPS would require authentication information from print clients. See comment #8 for more detailed information. The short story is: if authentication information is required by the queue, the print dialog needs to provide it when it submits the job. A work-around until that time is to hard-code the username and password into the queue's device URI, as before.
Created attachment 343991 [details] working printers.conf As you can see, there is no username nor password in the URI. With the AuthInfoRequired line commented out, I'm able to print as many jobs as I want. It is possible that the “working” state before was limited to one job - I'm not printing that much. Nevertheless, if you uncomment the said line in the printers.conf file, not even one job will complete.
Thanks for the confirmation. The problem is indeed due to the lack of an authentication dialog in the GTK+ print dialog. Jobs without an auth-info attribute will be rejected. (Note that printers.conf is dynamically updated by cupsd all the time.) There are good reasons for requiring the authentication to be at job submission time, as I've already explained above in comment #8.
Marek, does the cups backend pay attention to the auth-info-required attribute, currently ?
Hi Matthias, the backend doesn't handle the auth-info-required attribute yet. I'm going to have a look at it. Regards Marek
Hi, authentication of printing in gtk2 is a new feature which will not be implemented in Fedora 10. Authentication of printing is partially supported in Fedora 11 but the samba support (the auth-info attribute) is not finished yet. Samba support will be added to actual release when it become available. Regards Marek
Support for Samba printing was added in gtk2-2.18.0-1 in Fedora 12 (actual rawhide). Marek