Bug 119738 - Setup for SMB printer doesn't accept SMB server name
Summary: Setup for SMB printer doesn't accept SMB server name
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-printer   
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-01 21:58 UTC by Brion Vibber
Modified: 2008-05-06 23:58 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 23:58:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Stick an error message with suggestions between the endless series of dialogs (1.07 KB, patch)
2004-05-02 00:59 UTC, Brion Vibber
no flags Details | Diff

Description Brion Vibber 2004-04-01 21:58:06 UTC
Description of problem:
Configuring a remote printer hosted on a Windows XP machine, on a home network 
without local DNS. Putting the SMB name in for "Server" results in a never-ending series of 
identical "Authentication" dialogs with no hint of the problem; when I tried using the IP 
address in place of the name, or adding the name to /etc/hosts, configuration continued 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run system-config-printer as root under X
2. Add new print queue, give it a name, select Networked Windows (SMB) queue type.
3. Hit 'Specify...', and in the 'Authentication' dialog fill in names for Workgorup, Server, 
Share, User name, and Password. Use a SMB server name for which there isn't a DNS or 
hosts file entry.

Actual results:
The dialog disappears, then immediately reappears when submitted with OK button. There 
is no indication of what the problem is.

Expected results:
It should go out and look up the IP address, or else display an error message explaining 
that an IP or hostname might work better.

Additional info:
Running with SELinux in 'enforced' mode. Nothing shows up in /var/log/messages during 
this stage of configuration.
Even after configuring the printer using an IP address, it won't *print*. but that's for 
another bug report...

Comment 1 Tim Waugh 2004-04-30 16:00:57 UTC
Does it work in non-enforcing mode?  If so, could you see what
messages are produced in the output from 'dmesg'?

Comment 2 Brion Vibber 2004-05-01 11:43:03 UTC
I've still got the problem on a fresh install of test3, which allegedly has SElinux off by 

Nothing shows up in /var/log/messages (or in dmesg) during this part of printer 
configuration. Earlier there was a bunch of stuff of this sort:
security_context_to_sid: called before initial load_policy on unknown context system_u:
followed by a bunch of other such lines for all kinds of services. This doesn't look related.

As with test2, using the (non-DNS) SMB name causes the neverending unexplained series 
of authenticate dialogs. Putting in the IP address lets me successfully configure the printer 
(and I can even print now! yay)

Comment 3 Brion Vibber 2004-05-01 12:15:28 UTC
On further investigation, the problem with not accepting the SMB name is actually caused 
by the firewall. The default firewall settings break SMB browsing (bug 113918) and 
apparently even SMB name resolution. With the firewall off, I can put in the SMB name 
instead of the IP address; the machine also shows up in the available share list for handier 

Now, the firewall stuff is a separate bug, but the infinite series of 'Authentication' dialogs 
is still a problem in system-config-printer. If it could inform the user that it was unable to 
contact the printer (and perhaps suggest alternatives), that would be a big improvement.

Comment 4 Brion Vibber 2004-05-02 00:59:32 UTC
Created attachment 99869 [details]
Stick an error message with suggestions between the endless series of dialogs

If can't connect to printer, spits out "Check the machine name, share name,
username, and password. If the firewall is enabled, you may need to use an IP
address for the machine name." before prompting again.

Comment 5 John Thacker 2006-10-29 22:50:09 UTC
[This is a mass update sent to many bugs that missed earlier such messages due
to having their version set to a test version.]

This bug was originally filed against a version of Fedora Core which is no
longer supported, even for security updates.  Many changes have occured since
then.  Please retest this bug against a still supported version.  Note that FC3
and FC4 are supported by Fedora Legacy for security fixes only.  If
it still occurs on FC5 or FC6, please assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

This bug will be closed after a few weeks if no information is given indicating
that the bug is still present in a supported release.

Comment 6 Bug Zapper 2008-04-03 15:33:06 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 7 Bug Zapper 2008-05-06 23:58:25 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:

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