Bug 1743756 - print jobs fail with "Credentials required in order to print" after upgrade from F29->F30
Summary: print jobs fail with "Credentials required in order to print" after upgrade f...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: samba
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Guenther Deschner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1728452 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-20 15:47 UTC by Eric Blake
Modified: 2021-05-25 15:03 UTC (History)
16 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-05-25 15:03:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
overall cups log while trying a test page (1.02 MB, text/plain)
2019-08-20 15:48 UTC, Eric Blake
no flags Details
cups job log for a test page (10.43 KB, text/plain)
2019-08-20 15:49 UTC, Eric Blake
no flags Details
system-config-print troubleshooter output (34.19 KB, text/plain)
2019-08-20 16:03 UTC, Eric Blake
no flags Details
configuration that worked under Fedora 29 (882 bytes, text/plain)
2019-09-29 15:40 UTC, Eric Blake
no flags Details

Description Eric Blake 2019-08-20 15:47:36 UTC
Description of problem:
Ever since upgrading from Fedora 29 to Fedora 30, I've been unable to print to my  Pantum P2502W printer exposed over Samba. The failure message is "Credentials required in order to print", although I never had to supply credentials in F29.  The printer is connected via USB to a ReadyNAS box running Linux 2.6.17 and cupsys 1.1.14-5woody12.netgear1, which is then exposing it over smb://.  Comparing the files in /etc, the only real change I see after the upgrade to F29 is:

 <DefaultPrinter P2500W_serie>
 UUID urn:uuid:8733f299-dd6b-36a1-674a-9ec8e8c27cb2
+AuthInfoRequired none
 Info Pantum P2500W series

but trying to comment or remove that line doesn't change the symptoms.

Version-Release number of selected component (if applicable):
cups-2.2.11-3.fc30.x86_64

How reproducible:


Steps to Reproduce:
1. Open GNOME control panel to printers, select my printer, and select 'print test page'
2. Also try observing the job status from http://localhost:631, the 'Release job' button makes no difference
3.

Actual results:
after a few seconds, the status changes to "Requires Authentication", but with no dialog box asking for authentication, and the job never progresses

Expected results:
Print without needing authentication, as I used to be able to do under Fedora 29

Additional info:
will follow up with attachments per https://fedoraproject.org/wiki/How_to_debug_printing_problems

Comment 1 Eric Blake 2019-08-20 15:48:28 UTC
Created attachment 1606138 [details]
overall cups log while trying a test page

Comment 2 Eric Blake 2019-08-20 15:49:19 UTC
Created attachment 1606139 [details]
cups job log for a test page

Comment 3 Eric Blake 2019-08-20 16:03:31 UTC
Created attachment 1606143 [details]
system-config-print troubleshooter output

Comment 4 Zdenek Dohnal 2019-09-18 13:51:30 UTC
Hi Eric,

thank you for reporting the issue and I'm sorry for responding this late.

I was able to get running my testing samba printer with following uri scheme (for the case when you want to authenticate automatically):

smb://<WORKGROUP>/<user>:<password>@<hostname/IP>/<print_queue_name>

For the case when credentials are not in URI and should be asked when a job is created I needed to add 'AuthInfoRequired username,password' into print queue's entry in /etc/cups/printers.conf. Then I was able to enter credentials through dialog.

Would you mind telling me how your current samba print queue was installed? Through system-config-printer? Because system-config-printer created bad uris for samba printer when I tested it.

Comment 5 Zdenek Dohnal 2019-09-18 13:52:20 UTC
*** Bug 1728452 has been marked as a duplicate of this bug. ***

Comment 6 Eric Blake 2019-09-29 15:40:03 UTC
(In reply to Zdenek Dohnal from comment #4)
> Hi Eric,
> 
> thank you for reporting the issue and I'm sorry for responding this late.
> 
> I was able to get running my testing samba printer with following uri scheme
> (for the case when you want to authenticate automatically):
> 
> smb://<WORKGROUP>/<user>:<password>@<hostname/IP>/<print_queue_name>

The printer does not need a password.  Under Fedora 29, it printed just fine, but reading through my changes under etckeeper, I see that I had indeed been unable to add the printer using gnome tools, and finally got it working when I used https://localhost:631/printers.

I'm attaching the configuration that worked in Fedora 29, and then quit working when I upgraded to F30.

> 
> For the case when credentials are not in URI and should be asked when a job
> is created I needed to add 'AuthInfoRequired username,password' into print
> queue's entry in /etc/cups/printers.conf. Then I was able to enter
> credentials through dialog.

But my problem is that it should NOT be asking me for credentials, but just printing.

> 
> Would you mind telling me how your current samba print queue was installed?
> Through system-config-printer? Because system-config-printer created bad
> uris for samba printer when I tested it.

I tried both through system-config-printer and directly from the cups management page, neither is getting me a working configuration under F30.

Any other steps I should try?

Comment 7 Eric Blake 2019-09-29 15:40:49 UTC
Created attachment 1620782 [details]
configuration that worked under Fedora 29

Comment 8 Zdenek Dohnal 2019-10-01 08:53:01 UTC
Do you mean you use kerberos for authentization of printing? Or don't you have any creds at all?

Comment 9 Eric Blake 2019-10-01 14:05:49 UTC
(In reply to Zdenek Dohnal from comment #8)
> Do you mean you use kerberos for authentization of printing? Or don't you
> have any creds at all?

My printer is connected to a Netgear ReadyNAS device on my home network, where I have root access; it is running an older distro (Linux 2.6.17.14ReadyNAS, appears to be based off a Debian fork), running an older version of cups (I'm not sure which, but the port 631 control page has a copyright date of 2005), so I do have some flexibility to tweak things there.

But my previous setup was that I was able to print with no creds at all - the cups server on the ReadyNAS device exposed the printer over smb://, and allowed anyone on the same subnet to send print jobs (because my firewall prevents unauthorized users from being on the subnet).  My wife's Windows machine is also able to send print jobs without problems.

Comment 10 Eric Blake 2019-10-01 14:09:29 UTC
I could also be wrong in assuming that no creds are needed; perhaps Fedora 29 and Windows managed to ask for a one-time creds, so that all future access to the printer reused that earlier credential without me having to type it in every time (since getting a working setup is a one-time deal, and my etckeeper timestamps said I last got it working in Dec 2018, I could have forgotten whatever details were needed getting it set up) - but I _do_ know that the etckeeper history of my printers.conf did not show any captured username/password, and that under Fedora 29, I was not typing in a password for every print job.

Comment 11 Zdenek Dohnal 2019-10-01 15:15:41 UTC
Hmm... samba backend itself, which is part of samba, should take care of authentication to samba share if I understand it correctly.

I took virtual machine of F29 and tried to print on samba printer and I had installed cups from F30 and printing went well.

I would say a change in samba (samba got rebased between F29 and F30) is causing this behavior.

Comment 12 Zdenek Dohnal 2019-10-01 15:18:58 UTC
Guenther,

would you mind helping me with the issue? 

I created testing samba printer as Eric has and it works without any auth in F29, but when I use the same uri in F30, smb backend returns it as failed auth. I needed to specify workgroup, username and password for samba share to make it work.

Is it intentional?

Comment 13 Andreas Schneider 2019-10-02 06:31:17 UTC
I've thought about this in the past. If the AUTH is set to none I think we should try an anonymous connection. I can implement that.

Comment 14 Yaroslav Kraynov 2019-11-02 16:15:05 UTC
Hello,

I have a similar issue on Ubuntu 18.04 - ReadyNAS server with no user credentials configured and a USB printer attached it.

The USB printer is configured as SMB printer (Printer_SMB_1) on my machine and is working like this for years.

So my experience is the following:

1. Recently I bought a new WIFI router (Router2) as a secondary one. It manages its own subnet (Subnet2) through DHCP. The primary WIFI router (Router1) is the one provided by my ISP (it manages also its own subnet too - Subnet1). My ReadyNAS server is connected to Router1, having an IP address from the Subnet1.

2. When I am connected to Router1 there are no problems with printing using Printer_SMB_1 configuration.

3. When I am connected to Router2, my initial SMB printer config does not work (Printer_SMB_1), as it is based on the SMB path, which is not resolvable (the SMB shares form the Router1 (Subnet1) cannot be discovered by my machine with the SMB broadcast):
   a. I created a new SMB config for this printer (Printer_SMB__WITH_IP), by using the IP address of the printer. The printer is accessible, but for every printing an authentication window pops up.
      1. I created intentionally some user with password on the ReadyNas server and tried to use them - no difference.
      2. I entered my credentials on my machine - SUCCESS!!! (which is weird - a local user authentication/root access is needed to print on SMB server configured with IP address)

4. When I am connected to Router1 again:
   a. no problems with printing using Printer_SMB_1 configuration.
   b. printing with configuration Printer_SMB__WITH_IP still asks for local user credentials. (the same - a local user authentication/root access is needed to print on SMB server configured with IP address)

Any ideas?

Comment 15 Yaroslav Kraynov 2019-11-02 16:33:02 UTC
p.s. In cases (3.a) and (4.b) there is no SMB negotiation/traffic on port 445 (as seen in wireshark) BEFORE the local credentials are entered in the auth. window. After entering the local credentials, the negotiation traffic starts, where the following SMB user is provided by the the printing client (my machine): \\{THE_WORKGROUP_FROM_THE_LOCAL_SMB_CONF}\{the_local_user_name}

while in the case (4.a) the negotiated user is \\{THE_READYNAS_CONFIGURED_WORKGROUP}\lp

Comment 16 Yaroslav Kraynov 2019-11-02 16:35:02 UTC
p.s. 2 My initial problem was solved by adding the ReadyNAS server to /etc/hosts, but issues (3.a) and (4.b) still exist.

Comment 17 Andreas Schneider 2019-11-04 08:20:01 UTC
This is https://bugzilla.samba.org/show_bug.cgi?id=14128

Comment 18 Ben Cotton 2020-04-30 20:42:52 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 19 Eric Blake 2020-04-30 20:48:50 UTC
I still can't print on Fedora 31; I'm about to upgrade to Fedora 32 to see if the problem still persists

Comment 20 Eric Blake 2020-05-01 14:59:47 UTC
After upgrading to Fedora 32, I'm still having problems.  Browsing to:
https://localhost:631/printers/
and selecting my printer, then maintenance, print test page, I see:
processing since
Fri 01 May 2020 09:56:50 AM CDT 
"Connection failed: NT_STATUS_CONNECTION_DISCONNECTED"

but Windows machines in my subnet have no problem printing.  I'd welcome any advice on what troubleshooting steps I can take to help you fix this.

Comment 21 Fedora Program Management 2021-04-29 15:56:51 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 22 Ben Cotton 2021-05-25 15:03:50 UTC
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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