I have a printer share configured and want to access the printer properties from my WinXP client. start/run: \\server - enter username/passwd, enter the "Printers and Faxes" folder and right-click/properties on the printer. Message is "Printer properties cannot be displayed, operation could not be completed" The thing is that if i use the ip address like \\192.168.1.1 instead of the hostname, when connecting to the server from the client, it works just fine. my server does not have working dns configuration for the local machines, so server cannot lookup(forward/reverse) itself, nor the client using DNS... it's all in the server's /etc/hosts file, though! this happens on several systems (fedora core 2) with 3.0.5rc1 let me know if you're able to reproduce right away og if you need me to create some additional logs or something
Created attachment 561 [details] level 10 log of the problem happening
downgrading to fedora samba packages 3.0.3-5 with the same configuration and all, does not exhibit this behaviour!
looking in the log file, i saw an entry saying "get_called_name: assuming that client used IP address [192.168.1.254] as called name." which i though migh do something bad when we're not using the ip address... Our security token may not match \\ipaddress when we created against \\servername. get_called_name says that anything that comes in on port 445 should be able to work with only ip address, so to test that out i blocked port 445 in my firewall making sure i'm talking on port 139 instead. Problem is gone! So where to fix this?
further testing : to further prove my point about the token credential stuff, i tried to modify nt_printing.c:get_a_printer_2 to not return result from get_called_name as servername but to my hardcoded servername... now it works. My best guess with my limited knowledge of samba internals is that we should fix get_called_name to actually return whatever was used when establishing the connection... This seems to be the only way we can be sure that the credentials are okay. So problem now is (for me at least) where do we get the name that the client used when connecting to the server. Do we already have that lying around somewhere?
we do that now. The problem you have I think is that you dfon't have reverse DNS so smbd cannot match the IP to a name. Try just setting 'smb ports = 139' in smb.conf.
The best way as I see it would be to somehow retrieve exactly what the clien used for connecting... doing reverse lookup might solve my present problem if the dns domain part was filtered out... if i DO connect by ip address, doing reverse lookup would break in eaxctly the same way. Or should I choose to connect by FQDN name, neither of the above would work. the get_calling_name calls client_socket_addr function - no reverse lookup is attempted (not here at least) and the get_calling name is always used for the get_a_printer_2 call. Doesn't the client send it's actual connect details during session setup?
smb ports = 139 works just like blocking 445 in the firewall
Created attachment 569 [details] network trace of the problem happening
The correct way to implement this apparently is to save the server name sent in the OpenPrinterEx() call and then reuse that for all replies on that printer handle. I'll work on this.
*** Bug 1707 has been marked as a duplicate of this bug. ***
*** Bug 1817 has been marked as a duplicate of this bug. ***
*** Bug 1824 has been marked as a duplicate of this bug. ***
Created attachment 685 [details] save the hostname used in the openprinterex() for replies proposed patch
*** Bug 1859 has been marked as a duplicate of this bug. ***
changes checked into 3.0
(In reply to comment #13) We tested the patch with 3.0.8pre1 and it works! Thanks!
Tested with 3.0.8pre1 + patch, seems to work! I do have some other problems related to driver uploading, but i very muct doubt that it has something to do with this bug, so i'm all for closing it! :-) Thanks a lot!
We have Samba 3.0.7 installed on a shared storage (2 Servers named "buran" and "energija" are connected to the storage) so that we can start it either on "buran" or "energija". We use the following configuration to make samba listen on a own "application name" and ip-address (DNS:samba=10.96.70.14): interfaces = 10.96.70.14 bind interfaces only = Yes socket address = 10.96.70.14 netbios name = SAMBA server string = Samba %v We also have the problem that printers are connected with "printername on 10.96.70.14" on the clients. We tested Samba 3.0.8pre1 with the patch and everything worked fine. So we wanted to know if we can/should use the patch with samba 3.0.7 in our production environment.
The patch is stable as far as I know but it probably needs more testing to weed out any corner case failures. However, all the general functionality that I tested should be ok. So you'll have to be the judge of whether or not to use it in a production environment.
(In reply to comment #19) > The patch is stable as far as I know but it probably needs more > testing to weed out any corner case failures. However, all the general > functionality that I tested should be ok. So you'll have to be the judge > of whether or not to use it in a production environment. After this patch we cannot upload printer drivers on samba server (tested with 3.0.7 and 3.0.8pre1). "Add Printer Driver Wizard" got error: "unable to install HP LaserJet 4200 PCL 6, Windows 2000, Intel driver: Operation could not be completed". On samba 3.0.7 and 3.0.8pre1 without this patch uploading printer drivers works fine. smbd.log (log level=5): ... rpc_server/srv_spoolss_nt.c:getprinterdriverdir_level_1(7714) printer driver directory: [\\\\moran\print$\W32X86] ... I have found the reason of a error \\\\servername: --- patch-ip.orig Sun Oct 3 17:13:18 2004 +++ patch-ip Tue Oct 12 14:32:39 2004 @@ -920,7 +920,7 @@ return WERR_NOMEM; - slprintf(path, sizeof(path)-1, "\\\\%s\\print$\\%s", get_called_name(), short_archi); -+ slprintf(path, sizeof(path)-1, "\\\\%s\\print$\\%s", servername, short_archi); ++ slprintf(path, sizeof(path)-1, "%s\\print$\\%s", servername, short_archi); DEBUG(4,("printer driver directory: [%s]\n", path)); Thanks!
The issue has been fixed in the 3.0 svn tree (will be in 3.0.8pre2) See Bug 1907
Created attachment 724 [details] xp client log level 10 crash smbd
Patch of bug 1519: smbd crashed. Situation of test: Server: RHL9 Samba version: 3.0.4 as domain member of a W2k3 ADS. netbios name Samba server: dussel IP address Samba server: 192.168.100.151 DNS name Samba server: dussel.nh-hoteles.com CUPS printer queue name: DUSSEL_LASER01 Start, Run: \\dussel - enter username/passwd, enter the "Printers and Faxes" folder and right-click/properties on the printer (printername: DUSSEL_LASER01) Dialog window reports: "DUSSEL_LASER01 on dussel Properties" right-click/connect on the printer; "Connecting to DUSSEL_LASER01 on dussel" message appears. Login XP client. Users (XP clients) get printers applied via ADS logon script as: \\DUSSEL.NH-HOTELES.COM\DUSSEL_LASER01 Start, Settings, Printers and Faxes; printer "DUSSEL_LASER01 on dussel" appears. In the registery the following key appears: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\LanMan Print Services\Servers\dussel\Printers\DUSSEL_LASER01] This behavior is Ok. Upgrade to Samba version: 3.0.7 (applied with patch of bug 1519) Start, Run: \\dussel - enter username/passwd, enter the "Printers and Faxes" folder and right-click/properties on the printer (printername: DUSSEL_LASER01) Dialog window reports: "DUSSEL_LASER01 on dussel Properties" right-click/connect on the printer; "Connecting to DUSSEL_LASER01 on dussel" message appears. (the description of bug 1519 is resolved then). User profile on XP client deleted. Login XP client. Users (XP clients) get printers applied via ADS logon script as: \\DUSSEL.NH-HOTELES.COM\DUSSEL_LASER01 Start, Settings, Printers and Faxes; printer "DUSSEL_LASER01 on DUSSEL.NH-HOTELES.COM" appears. In the registery the following key appears: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\LanMan Print Services\Servers\DUSSEL.NH-HOTELES.COM\Printers\DUSSEL_LASER01] Logoff client. Login client. Only home share is made. smbd crashed with: 2004/10/13 14:54:57, 0] lib/util.c:smb_panic2(1381) PANIC: internal error [2004/10/13 14:54:57, 0] lib/util.c:smb_panic2(1389) BACKTRACE: 24 stack frames: #0 smbd(smb_panic2+0x128) [0x81d5098] #1 smbd(smb_panic+0x19) [0x81d4f69] #2 smbd [0x81c2fd2] #3 /lib/tls/libc.so.6 [0x420275c8] #4 smbd [0x81f9c96] #5 smbd(free_a_printer+0x6b) [0x81fdf4b] #6 smbd(_spoolss_getjob+0x1c5) [0x81381f5] #7 smbd [0x81240c1] #8 smbd(api_rpcTNP+0x159) [0x8154ce9] #9 smbd(api_pipe_request+0xaf) [0x8154aaf] #10 smbd [0x814df74] #11 smbd [0x814e2b9] #12 smbd [0x814e4fb] #13 smbd [0x814e6fc] #14 smbd(write_to_pipe+0xf2) [0x814e652] #15 smbd [0x808bb9e] #16 smbd(reply_trans+0x54b) [0x808c56b] #17 smbd [0x80d0ca6] #18 smbd [0x80d0e89] #19 smbd(process_smb+0x8f) [0x80d109f] #20 smbd(smbd_process+0x167) [0x80d1d77] #21 smbd(main+0x4db) [0x824831b] #22 /lib/tls/libc.so.6(__libc_start_main+0xe4) [0x42015574] #23 smbd(yp_get_default_domain+0xad) [0x80787c1] [2004/10/13 14:55:08, 6] param/loadparm.c:lp_file_list_changed(2681) lp_file_list_changed() Attached log level 10 of XP client logon and re-logon
reopening since there was a few issues with the original patch
Created attachment 725 [details] second draft of complete patch against 3.0.7 This patch includes the fixes for the original bug report, BUG 1907, and a patch from a segfault uncovered by the original patch.
Created attachment 733 [details] logs + updates of v2 patch bug 1519 Version 2 of the patch causes still crashes of smbd: [2004/10/18 17:05:01, 0] lib/fault.c:fault_report(36) =============================================================== [2004/10/18 17:05:01, 0] lib/fault.c:fault_report(37) INTERNAL ERROR: Signal 11 in pid 31982 (3.0.7) Please read the appendix Bugs of the Samba HOWTO collection [2004/10/18 17:05:01, 0] lib/fault.c:fault_report(39) =============================================================== [2004/10/18 17:05:01, 0] lib/util.c:smb_panic2(1381) PANIC: internal error [2004/10/18 17:05:01, 0] lib/util.c:smb_panic2(1389) BACKTRACE: 23 stack frames: #0 smbd(smb_panic2+0x128) [0x81d5108] #1 smbd(smb_panic+0x19) [0x81d4fd9] #2 smbd [0x81c3042] #3 /lib/tls/libc.so.6 [0x420275c8] #4 smbd(free_a_printer+0x6b) [0x81fdfbb] #5 smbd(_spoolss_getjob+0x1c5) [0x8138265] #6 smbd [0x81240c1] #7 smbd(api_rpcTNP+0x159) [0x8154d59] #8 smbd(api_pipe_request+0xaf) [0x8154b1f] #9 smbd [0x814dfe4] #10 smbd [0x814e329] #11 smbd [0x814e56b] #12 smbd [0x814e76c] #13 smbd(write_to_pipe+0xf2) [0x814e6c2] #14 smbd [0x808bb9e] #15 smbd(reply_trans+0x54b) [0x808c56b] #16 smbd [0x80d0ca6] #17 smbd [0x80d0e89] #18 smbd(process_smb+0x8f) [0x80d109f] #19 smbd(smbd_process+0x167) [0x80d1d77] #20 smbd(main+0x4db) [0x824838b] #21 /lib/tls/libc.so.6(__libc_start_main+0xe4) [0x42015574] #22 smbd(yp_get_default_domain+0xad) [0x80787c1] In attached ZIP you'll find the log files of the XP client. The log files start with a description of the test. Also included in the ZIP file: the files that are altered during applying the patch (for check and double check purposes) and used for compiling the rpm.
Created attachment 734 [details] 3rd revision of patch which should be the charm I think
The 3rd version of the patch should fix things all around (including the reported segfault).
(In reply to comment #28) > The 3rd version of the patch should fix things all around (including > the reported segfault). I've just applied the 3rd version of the patch to 3.0.7 and recompiled, but am still seeing both the <printername> on <ipaddress> problem and point and print driver download capability problems on some (but not all) client machines (some are 2k and some are xp). This patch was supposed to fix those problems, right?
you will need to disconnect from the printers and reconnect as the client spooler is caching information.
originally against 3.0.5rc1 (which was 34.0.6rc1 due to the security release).
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.