remember password on printing to windows printers does not work

From which applications did you observe the problem? Does the problem occur with all applications, including OpenOffice.org? How does the password dialog look like? Is it always exactly the same for all applications?

you are right, the checkbox is only there, if i print from openoffice.
if i print from gedit or from evince, then there is no checkbox

These password dialogs are not the same and probably come from different packages. Most probably they come from the packages which contain the printing dialog (where you choose on which printer you want to print and how many copies). I assume they immediately appear after you click "Print" or "OK" at the bottom of the application's print dialog. GEdit most probably uses the printing dialog of GTK. provided by the GTK package) and OpenOffice.org has its own printing dialog. As the option to remember the password only appears in OpenOffice.org this bug report makes only sense there. Therefore I am moving it to OpenOffice.org.

Note also that system-config-printer is a printer setup tool. It is only used to set up print queues, configure default settings and the behavior of the printing system. system-config-printer is not called when printing out of an application.

Till, mightn't that be the dialog that system-config-printer-applet displays when it sees a job held for authentication?

This is possible, but why are the two dialogs different then? One contains the checkbox to remember the password and the other not. Also the text is different.

Tim, is the applet's dialog the one with or without the checkbox?

Tim, how does the applet's dialog remember the password? Are you able to reproduce the bug? Do you have a patch?

It uses gnome-keyring.

Tim, is there anything what can cause one job to trigger the pop-up of a password dialog with and another without the checkbox to remember the password?

I wouldn't have thought so.

i think it is important to add:
if i print with openoffice i have to wait some time for the dialog to appear
if i print with evince or gedit, it appears instantly

and another thing to add is that:
if i print with openoffice, the print icon appears before the dialog (the one that shows the active print jobs on click on it) in the statusbar
if i print with evince or gedit this icon does not appear before the dialog

I am also seeing this problem. I print more from Firefox than anything else, and it does not have the remember checkbox.

And it is truly annoying especially when you need to print a series of pages (i.e. web based email program, printing several emails to walk into a meeting).

Thunderbird, Krusader file view printing dialog has the "Remember" check-box. Also noticed when the dialog box active, Firefox uses 100% CPU until I press either OK or Cancel.

Same problem here, even when check box is present (open office), it does not remember the password.

All the rest of the programs do not have a remember check box.

Please someone fix, I have to enter my domain/firstname.lastname , and then my password each time I print with 9.10.
This problem did not exist in 9.04.

Matt

I'm having this same problem also. I hate to bump a dead thread, but this is a real pain in the ass.

OK well I found a solution that worked for me, not sure if this helps anyone else, but;

I originally was connecting to our office computer via
smb://192.168.48.5/admin01/HP-M1120MFP

But when I changed to connecting another way (browsing the network) via;
smb://CREW/ADMIN01/HP-M1120MFP

I no longer get asked for passwords.

Cheers
Matt

I have the same problems. It doesn't automatically authenticate, even though I have my samba password set up in my keyring (i.e., for browsing files). And OO has the checkbox to remember, while gedit does not.

In contrast to Matt's url, I am using smb://WORKGROUP/.../LaserJet. So maybe this affects workgroups and not Windows domains?

I've marked #503812 as a duplicate of this bug.

I have the same problem on Karmic with using a remote IPP printer queue that requires authentication.

The IPP username is not the same as my local username, so I have to change the username as well as enter the password for every printout.

Neither password nor username is remembered, even if I check "Remember Password" in the dialog (/usr/share/system-config-printer/authconn.py).

I get both versions (with/without the Remember Password checkbox) of the authentication dialog depending on which application I print from.

I have the same problem. I'm using Karma (9.10) and I'm printing to a Samba shared printer. I open the printer configuration dialog (system-config-printer), double-click on my printer, and click on "Change..." next to the device URI. After waiting some time while it's searching for printers (why is this necessary, by the way?), I select "Set authentication details now", enter my username and password and click on the "Apply" button. This has no effect whatsoever. When I reopen the dialog by clicking on "Change..." again, it has forgotten my username and password.

Indeed when I try printing from Document Viewer, it keeps asking me for my username and password every time.

I see the same as #18 and #19: "Set authentication details now" in the Device URI dialog has no seeming effect; I get asked for a password every time I print and the username is populated with my local id, which is incorrect. This is really annoying.

The printer is accessed using the SMB protocol. I can also see the printer in the network browser using IPP and LPD, but setting it up to use these protocols doesn't work (a test page just never appears at the printer).

If someone having this problem could kill system-config-printer-applet and re-start it like "system-config-printer-applet --debug", we'd be able to see what interactions with gnomekeyring are performed.

The gnomekeyring data that system-config-printer uses are stored under key {domain,server,protocol}, and has the item {user} in addition to the secret. Looking again at the code, I see that domain is stored case-sensitively, and server is always converted to lower case.

Take a look using seahorse to see which passwords are stored under which keys. For example, I have an IPP password stored with display name tim@1921.68.122.197, and in the details it says:

protocol: ipp
server: 192.168.122.197
user: tim

Attached is a log of two print jobs. The first is a test page and I wasn't prompted for a password. The second was a single page from evince and I was prompted, with the user name pre-filled to "chris". The printer name is wwh426 and its URI is smb://printserver.cims.nyu.edu/bwpr09. I have the following password entry in seahorse:

server: printserver.cims.nyu.edu
user: cconway
domain:
protocol: smb

Chris: the dialog you saw wasn't from system-config-printer-applet then, as far as I can tell. It only ever saw the job in state 'idle', 'processing', or 'completed'; never 'held'.

Any idea where it could be coming from? Here's a screenshot of the dialog opened by Google Chrome. This window title is "Authentication".

Status changed to 'Confirmed' because the bug affects multiple users.

Moving to GTK, as the password dialog seems not to come from system-config-printer.

Thanks for following up on this.

I would just like to confirm this bug, and that it's still a problem on ubuntu 11.10.

I have to write mydomain/username and password every time.

My username is actually remembed, but just that.

Is there any hack around it?

I have the same problem in Ubuntu 12.04
I have to write mydomain/username and password every time.
My username is actually remembed, but just that.

Anybody looking at this?

Problem still exists on 12.10.
Also only my username is remembered. Incorrectly, as I need to enter it in DOMAIN\username format to be accepted.

Exists for me on 12.04. Connecting to a Laserprinter on a windows network, when I connect directly.

I was able to solve this problem, like Matt Jones (#16) did, by using the full path (with workgroup). Here were the steps I took (12.04):

1. Open "Printing" via dash
2. Click "Add +"
3. Select "network printer"
4. Select "Windows Printer via Samba" (last option in list)
5. Click "Browse"
6. Choose your domain / workgroup from the list (it took me ~30s for the list to populate)
7. Locate the print server from your domain, and select it -- this may require you to authenticate via keyring
8. Select your printer
9. Choose "Set Authentication details now"
10. for "username" you may need to do the domain name first ("DOMAIN\username"), but try it without first. Clicking "Verify..." will not successfully verify this, but it will still work.
11. Proceed with printer installation (driver and whatnot)

Print a page from an app or print a test page -- it should do it without requiring authentication.

The process in #33 works for me, however, it leaves the user's password in clear text(!) in the file /etc/cups/printers.conf . This file is only readable by root, but if even root should not know user passwords.

Same problem here with Ubuntu 13.10 64bits
At work, I always get the documents held for authentication, and even if I tick the box, it does not remember either my login or password (the login always goes back to my computer's login name, and the password field is empty).

This bug is getting pretty old now: more than 4 years.

The issue seems an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

I think it is reported already in the Gnome bugtracker.
See https://bugzilla.gnome.org/show_bug.cgi?id=674264

Just wanted to report that I still have the same issue with Ubuntu 14.04 64 bits up to date.

The issue has been fixed upstream in that commit
https://git.gnome.org/browse/gtk+/commit/?id=382d68ff8e5701a10aa8d4f879c46c63c21e075f

SRU proposal for utopic (gtk+2.0)

SRU proposal for utopic (gtk+3.0)

@Dariusz, thanks for the work, I've uploaded the gtk+3.0 change to utopic. Let's get feedback there before considering a stable update. I would also like to see upstream comment/review the change for gtk2 before we get that in, if that's possible (seems they are still pondering if they want it there)

The attachment "gtk+2.0_2.24.24-0ubuntu2.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

This bug was fixed in the package gtk+3.0 - 3.12.2-0ubuntu9

---------------
gtk+3.0 (3.12.2-0ubuntu9) utopic; urgency=medium

  * Bump minimum version of gtk_print_backend_set_password due to addition of
    new boolean parameter.

gtk+3.0 (3.12.2-0ubuntu8) utopic; urgency=medium

  * debian/patches/use-secrets-service-for-cups-auth_info.patch
    - Stores auth_info in secrets service for printing (LP: #445333)
 -- Iain Lane <email address hidden> Fri, 26 Sep 2014 15:31:53 +0100

While I was working on a packport of this feature I have discovered a bug in the gtk printing backends (affects series 2 and 3) that may cause random crashes due to buffer overflow.

I have reported the issue upstream and am working on backports to utopic and trusty (gtk2 and gtk3).

https://bugzilla.gnome.org/show_bug.cgi?id=737777

SRU proposal for Utopic (https://bugzilla.gnome.org/show_bug.cgi?id=737777)

SRU proposal for utopic

Contains the feature backport along with a fix for https://bugzilla.gnome.org/show_bug.cgi?id=737777.

SRU proposal for trusty.

Contains feature backport along with a fix for https://bugzilla.gnome.org/show_bug.cgi?id=737777.

thanks, that looks correct but let's wait a bit for upstream review

The fix has been pulled in by the upstream:
https://git.gnome.org/browse/gtk+/commit/?id=15dbadf38992aa09364f0dd06a71a51b99b6e800

And the upstream bug (https://bugzilla.gnome.org/show_bug.cgi?id=737777) has been marked as resolved fixed.

thanks Dariusz, I've uploaded the segfault fix to utopic

Thanks Dariusz, Iain updated the symbol version in https://launchpad.net/ubuntu/+source/gtk+3.0/3.12.2-0ubuntu9

" * Bump minimum version of gtk_print_backend_set_password due to addition of
    new boolean parameter."

Could you update your SRU debdiff to do the same?

SRU proposal for utopic (gtk2)

SRU proposal for trusty (gtk3).

SRU proposal for trusty (gtk2).

Sebastien, please find the attached debdiffs with the gtk_print_backend_set_password version bumped.

Thanks!

Thanks, I've uploaded the trusty gtk3 version, the gtk2 one still needs review/to go in vivid before being SRUed

Sebastien, I have prepared a debdiff for gtk2 vivid. I hope it will be of any use for you. Thanks!

Hello segler, or anyone else affected,

Accepted gtk+3.0 into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gtk+3.0/3.10.8-0ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello,

I upgraded from trusty-proposed:
- libgail-3-0:amd64 3.10.8-0ubuntu1.3
- libgtk-3-0:amd64 3.10.8-0ubuntu1.3

Here is my test scenario (using gedit):

Nothing in gnome keyring
Print text1
A dialog asked for credentials (I fill and check "remember")
job is printed & credentials appear in gnome keyring

Print text2
no dialog appear, job is printed

Print text3
no dialog appear, job is printed

Then I deleted the credentials in gnome keyring
Print text4
A dialog asked again for credentials.

The new packages looks perfect to me! :)

This bug was fixed in the package gtk+3.0 - 3.10.8-0ubuntu1.3

---------------
gtk+3.0 (3.10.8-0ubuntu1.3) trusty; urgency=medium

  * debian/patches/use-secrets-service-for-cups-auth_info.patch
    - Stores auth_info in secrets service for printing (LP: #445333)
  * debian/patches/printing-initialize-auth_info.patch
    - Fix to an upstream bug:
      https://bugzilla.gnome.org/show_bug.cgi?id=737777
  * Bump minimum version of gtk_print_backend_set_password due to addition of
    new boolean parameter.
 -- Dariusz Gadomski <email address hidden> Tue, 23 Sep 2014 18:16:51 +0200

The verification of the Stable Release Update for gtk+3.0 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

The upstream gtk is considering backporting this change to gtk2: [1]

What I find most important in the description is:
With regards to the importance of having this only fixed in GTK 3. To be
honest, as long as firefox still uses GTK 2 in most distributions this fix is
more important for our users to have in GTK 2 then it is in GTK 3 :-/

This remains true for Ubuntu as well.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=743166

This bug was fixed in the package gtk+2.0 - 2.24.25-0ubuntu2

---------------
gtk+2.0 (2.24.25-0ubuntu2) vivid; urgency=medium

  * debian/patches/use-secrets-service-for-cups-auth_info.patch
    - Backport of auth_info storing (LP: #445333)
  * debian/patches/printing-initialize-auth_info.patch
    - Fix to an upstream bug:
      https://bugzilla.gnome.org/show_bug.cgi?id=737777
  * Bump minimum version of gtk_print_backend_set_password due to addition of
    new boolean parameter.
 -- Dariusz Gadomski <email address hidden> Fri, 21 Nov 2014 12:36:11 +0100

I've uploaded the gtk+2.0 debdiff to the Trusty queue for review by the Ubuntu SRU team.

Hello segler, or anyone else affected,

Accepted gtk+2.0 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gtk+2.0/2.24.23-0ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

sudo vi /etc/apt/sources.list
# snip
# Trusty Proposed -> test GTK2 patch https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/445333
deb http://archive.ubuntu.com/ubuntu/ trusty-proposed restricted main multiverse universe
# snap

sudo apt-get update
sudo apt-get install libgail-common libgail18 libgtk2.0-common libgtk2.0-bin libgtk2.0-0
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  libgail-common libgail18 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common
5 upgraded, 0 newly installed, 0 to remove and 209 not upgraded.
Need to get 1'994 kB of archives.
After this operation, 13.3 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main libgail-common amd64 2.24.23-0ubuntu1.2 [110 kB]
Get:2 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main libgtk2.0-common all 2.24.23-0ubuntu1.2 [121 kB]
Get:3 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main libgtk2.0-bin amd64 2.24.23-0ubuntu1.2 [9'798 B]
Get:4 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main libgail18 amd64 2.24.23-0ubuntu1.2 [14.1 kB]
Get:5 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main libgtk2.0-0 amd64 2.24.23-0ubuntu1.2 [1'739 kB]
Fetched 1'994 kB in 0s (4'148 kB/s)
[...]

I run the following test steps :

Initial status : Gnome keyring is empty

Step #1 :
 print from Firefox
 Nothing asked, new printer icon on top right of the screen. Click -> Job#1 is "Held for authentication"
 Right-click > Authenticate
 I Give the credentials and check the "Remember password". (attached "print_step1.png")
 Job is printed
 Gnome keyring gets a "Network password" entry "domain\<email address hidden> (smb)"

Step #2 :
 print from Firefox
 A dialog opens ans ask for authentication "Authentication is required to print document "Title" on printer printername.
 I Give the credentials and check the "Remember password". (attached "print_step2.png")
 Job is printed
 Gnome keyring gets a second "Password or secret" entry "ipp://localhost:631/printers/printername"

Step #3 and following :
 print from Firefox
 No dialog comes to the user
 Job is printed
 Gnome keyring has no more entries than the 2 said before.

To me this is the acceptable behaviour.
Ideal would even be to have step #1 asking interactively for credentials, step #2 skipped so that we get immediately step #3. But this is outside the scope of this bug report I think.

Thanks!
Samuel

Works perfectly for me. With an empty keychain, Firefox prompts for credentials and saves them in the keychain, and printing just works. Gedit (GTK3 application) is then able to use the same credentials, although they are a bit different from what GTK3 saves to the keychain.

This bug was fixed in the package gtk+2.0 - 2.24.23-0ubuntu1.2

---------------
gtk+2.0 (2.24.23-0ubuntu1.2) trusty; urgency=medium

  * debian/patches/use-secrets-service-for-cups-auth_info.patch
    - Backport of auth_info storing (LP: #445333)
  * debian/patches/printing-initialize-auth_info.patch
    - Fix to an upstream bug:
      https://bugzilla.gnome.org/show_bug.cgi?id=737777
  * Bump minimum version of gtk_print_backend_set_password due to addition of
    new boolean parameter.
 -- Dariusz Gadomski <email address hidden> Tue, 10 Mar 2015 08:20:43 -0700