smbd can't find the GUID for a printer in the registry and fails to publish printers. We should probably implement a function nt_printer_guid_retrieve() which gets the GUID from ldap if nt_printer_guid_get() fails to find the GUID in the registry. This issue occured with: https://bugzilla.samba.org/show_bug.cgi?id=9900 The issue also exists on Samba 4.x.
I have this bug too since going from RHEL 6.5 (Samba 3.6.9-169.el6) to 6.6 (Samba 3.6.23-12.el6). I have a support call open with Red Hat about this but have been unable to provide a step by step method for them to reproduce it, so they can backport a fix. First question is is this the same bug you see, when you right click the printer is and click connect the Windows machine returns "Windows cannot connect to the printer" "Operation failed with error 0x00000002". And the log has an entry "Failed to get GUID for printer". Downgrading (without changing anything on the driver fixes this).
Colin, Everything is described here : https://bugzilla.samba.org/show_bug.cgi?id=9900 And yes, I witness the exact same things as you. About the BZ 9900, it is very sad this bug has been closed as it is NOT fixed at all.
I was tempted to add an objectGUID registry entry into the Samba registry to see if this would workaround the issue. Though not sure what this value should be. Red Hat claim to be investigating, though I'm struggling to reproduce the issue consistently on a test system when adding new drivers, just consistently failing on my production print servers. Not sure what the exact cause of this difference is.
This may be related to bso#9900. "This bug has huge implications for printer publishing, as the DC queries the print server for publishing status (via level=7 GetPrinter) every eight hours and purges the AD PrintQueue object if the response does not match what the server expects (DSPRINT_PUBLISH with matching GUID)."
Red Hat created a test package but there is still no feedback if the created patchset fixes the bug. Talk to Red Hat support ...
Created attachment 10738 [details] patch for 4.2
Created attachment 10739 [details] patch for 4.1
Created attachment 10740 [details] patch for 4.0
Created attachment 10741 [details] patch for 3.6
Comment on attachment 10738 [details] patch for 4.2 GUID_buf_string() is only present in the master branch. All 4.X backports should be fixed.
Created attachment 10841 [details] patch for 4.2
Created attachment 10842 [details] patch for 4.1
Comment on attachment 10841 [details] patch for 4.2 LGTM, thanks Andreas.
Karolin, please add the patches to the relevant branches. Thanks!
Pushed to autobuild-v4-[1|2]-test.
(In reply to Karolin Seeger from comment #15) Pushed to both branches. Closing out bug report. Thanks!
For the record : I confirm that in 3.6.23-20.0.1, this bug is still present, and the only workaround (kindly suggested by Colin Simpson - THANK YOU SO MUCH) is to : - stop the services - export the registry - change the 14th bit of the Attribute key from 1 to 0, responsible for the checkbox "Publish in Active directory" - save, import, restart I can't wait to see the 3.6.24 been published in the CentOS repos, as I may have understood this was fixed in this version.
(In reply to Nec from comment #17) > For the record : > I confirm that in 3.6.23-20.0.1, this bug is still present, and the only > workaround (kindly suggested by Colin Simpson - THANK YOU SO MUCH) is to : > - stop the services > - export the registry > - change the 14th bit of the Attribute key from 1 to 0, > responsible for the checkbox "Publish in Active directory" So if I get this whole thing right, the problem seems to be that somehow that flag 'Publish in AD' go set in Samba's registry but the printer was in fact not published. And it was also not the intention to publish it. Is that correct? It seems we need to understand how this situation could get created. But this sounds different from the description of this bug, so maybe it is a new bug (possibly with the same resulting error message). Then we should track it as a new bug... > - save, import, restart > I can't wait to see the 3.6.24 been published in the CentOS repos, > as I may have understood this was fixed in this version. No, sorry. Samba 3.6 is out of maintenance. It 3.6.24 was a security release. see: https://wiki.samba.org/index.php/Samba_Release_Planning You may get such fixes backported via downstream vendors/distributors. which is why you may see the patches for 3.6 on Bugs here.
(In reply to Michael Adam from comment #18) > So if I get this whole thing right, the problem seems to be > that somehow that flag 'Publish in AD' go set in Samba's > registry but the printer was in fact not published. And it > was also not the intention to publish it. Is that correct? That's it. Not sure why this causes a GUID issue with connecting to it. > > It seems we need to understand how this situation could get created. I don't know in my case how it got created. But I maybe wanted to try publishing the printer at some point, it set the Samba registry to say it had but failed to actually do this. Certainly unticking now will not succeed unless AD unpublishing is successful. So this make the registry hacking necessary to undo this. > > But this sounds different from the description of this bug, > so maybe it is a new bug (possibly with the same resulting > error message). Then we should track it as a new bug...
(In reply to Colin Simpson from comment #19) Absolutely confirming every point raised by Colin.
If I get it right, this is a new bug, that 'net ads printer remove' should have an option '--force' to remove the publish bit from the Samba registry, even if we fail to contact the AD server or the printer is not published in AD?
(In reply to Andreas Schneider from comment #21) > If I get it right, this is a new bug, that 'net ads printer remove' should > have an option '--force' to remove the publish bit from the Samba registry, > even if we fail to contact the AD server or the printer is not published in > AD? I think we need to understand the following things: - Is the creation of this inconsistent changes somehow triggered by the fixes of this bug? Or more precisely, is there something that we could do in the code to prevent this being created? - If there is such a situation, is there a chance that samba can react better than failing with message that the guid was not found? (Maybe not..) - Finally, yes we should provide a tool to force the removal of the publish bit as you described. My 2 cents...
Yes, I agree. We do not have enough information to fully understand the problem or the description for a reproducer.
It's should be pretty easy to reproduce this "bug". If it is a bug, it's more a change of behaviour i.e. if "List in Directory" was ticked but it isn't published really in AD (removed by some other means etc), it will no longer allow you to "Connect" to it. It used to. But you also cannot untick "List in Director" in the GUI as Samba can't find the printer in AD (funally enough as it isn't published). But maybe it should still allow this to be unticked, even if not in AD? Not sure... To reproduce: 1/ Ensure you have a printer that isn't published in AD, and "List in Directory" is unticked. And ensure you can install drivers for it. 2/ Stop Samba 3/ net registry export HKLM /root/samba.reg 3/ Then edit /root/samba.reg and look for the keys like: HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Print\Printers\Printername Where Printername is the name of your printer. For example I have a key. [HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\dell3130cn1] my printer is called "dell3130cn1". 4/ Under here there is an entry "Attributes". From my case: "Attributes"=dword:00001848" The "List in Directory" setting appears to be controlled by bit 14 (counting from least significant) In practice we have the same value (presumably all other settings represented by this key are common to all our printers) so it was easy i.e. I have List in Directory NOT set - 01100001001000 - 6216(decimal) - 1848 (hex) List in Directory set - 11100001001000 - 14408 (decimal) - 3848 (hex) Put in a new value with this bit 14 flipped to 1 (and the rest of the values as before) and convert back into hex. Then this is your new value for this attributes key. For my case change to: "Attributes"=dword:00003848" 6/ Import this edited registry back into Samba. net registry import /root/samba.reg 7/ Start Samba and see if from a Windows machine this "List in Directory" is now set. 8/ Trying to install the drivers should now fail (if you cleared out Windows of the driver installs). 9/ Also observe that the "List in Directory" tick box cannot be unticked. Hope this helps.....and not just confuses.
Colin, could you please open a new bug with the information you provided? Thanks.
New bug report opened Bug#11665 'When connecting to printers with "List in Directory" set but aren't in the directory fails'. Not sure exactly which versions of Samba are effected by this.