Samba printers requiring username/password fail on reboot

Bug #113637 reported by PeteDonnell
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cupsys (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Printers at my work are only accessible via Samba, with a valid username and password. I add them through the KDE System Settings->Printers dialogue, as SMB printers, using my username and password. On initial setup, they work fine (both a Samsung CLP-500 using the splix drivers and a Kyocera Mita 3035 using the default drivers that ship with Ubuntu). On reboot, they no longer work, as in no document or test page sent to either printer seems to get through, no error messages come back (that I have found), it just says "Document successfully sent to the printer" and that's the last I hear.

Similar problems seem to have been mentioned on the KDE-print-devel list, e.g. at http://mail.kde.org/pipermail/kde-print-devel/2007-February/001563.html, so this may well be an upstream bug. The problem seems to be related to the device uri. When a printer has initially been added, in the KDE printer setup program main page, selecting the printer shows its info, which contains the following line:
Device: smb://workgroup/SERVER/networkprintername

After reboot, its info appears instead as
Device: smb://username:pass (truncated)

In both cases, these strings match the value returned by 'lpstat -v localprintername'. I've tried manually setting the Device info back to what it initially appears as, via 'lpadmin -p localprintername -v smb://workgroup/SERVER/networkprintername' but this doesn't appear to fix the problem.

It's almost certainly related to the fact that my network samba password contains a hash ('#') character. Before reboot, when the printers are working fine, my username and password do not appear in the Device info. After reboot, when the printers no longer work, the Device info contains my username, my password up to but not including the # character, and nothing else. The workgroup, server and printer name have all disappeared.

I'm aware that accessing a printer via username/password over samba is not recommended by the cups team for security reasons, but I don't have much choice. It's strange to me that the printer works initially, but something in the reboot process screws with the settings and causes this breakage. It's not the end of the world, but I'd like to find some kind of workaround for this and I currently just don't know enough about how the printing system works to go any further. I've tried looking for a config file that stores the network credentials for use of the printer, so that I can escape the # by changing it to a %23 (if that's the correct uri escape character), but so far haven't been able to find it. Ideally of course, a proper fix would be available as opposed to a workaround.

If this is an upstream bug, please let me know so I can report it there instead/as well. At the moment I'm not sure if the problem lies with smbspool, or with the KDE Printer setup's method of hiding the username & password for a samba printer uri, or something else.

For info, I'm running Kubuntu 7.04, currently fully up-to-date.

Revision history for this message
Markus Thielmann (thielmann) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better.

This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers.
You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage .

I have classified this bug as a bug in "cupsys".

Revision history for this message
Daniel T Chen (crimsun) wrote :

Is this symptom still reproducible in 8.10 beta?

Changed in cupsys:
status: New → Incomplete
Revision history for this message
ororo (ororo) wrote :

I have the same problem in Kubuntu 8.04

Revision history for this message
ororo (ororo) wrote :

Seems to be solved in Kubuntu 8.10
...of course here there are lots of other problems...

Revision history for this message
Christopher (soft-kristal) wrote :

My CLP-500 works fine in Jaunty, but not in Karmic. I have tried it on two separate machines and get the same splix error.

I am appending the troubleshooting file.

Revision history for this message
Christopher (soft-kristal) wrote :

A further note - I can print from the laptop using Karmic via samba to the CLP-500 attached to my home network but only when the computer physically attached to the printer is running Jaunty. When I run Karmic on that computer, I cannot print via network or locally.

I still can't scan from my HP OfficeJet 4215 using Karmic, but I can print and fax.

Revision history for this message
fbiondi (filomail) wrote :

at office I can print only via samba. Before Karmic all was ok, now i have a strange behavior.
In system-config-printer 1.1.12 I configure my printer and in "Change Device Uri" window I set username and password in "Authentication: set authentication details now".
Click on "Verify" button and the result is : "Print Share Verified...the print share is accessible", then click on "Apply".
Unfortunately when I try to print an "Authetication" window, asking for username and password, pops up repeatedly...

this works fine:
 echo -en "\rHello\r\f" | smbclient "//myPrinterShare "myPassword" -c "print -" -U "myUser" -W "myWorkgroup"

Revision history for this message
Alexander Sashnov (sashnov) wrote :

answer on comment #7 from fbiondi:

Same here but it is not a bug. On karmic you just need to add your work group into printer url:

This works on hardy:
   smb://192.168.34.24/LexmarkT

On karmic:
   smb://WORKGROUP/192.168.34.24/LexmarkT

Revision history for this message
fbiondi (filomail) wrote :

Yes, It works for me!

Thx a lot.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for cupsys (Ubuntu) because there has been no activity for 60 days.]

Changed in cupsys (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.