Created attachment 17027 [details] log.smbd Since the upgrade from 4.11 to 4.13 Samba returns an empty list of printers. $ rpcclient localhost -c 'timeout 90000; enumprinters' Enter korobkin's password: timeout is 90000 No printers returned. Local CUPS exports about 800 printers, and Samba 4.11 used to work with them OK, but 4.13 fails to get a list. These lines seem to be the most suspicious in the log: [2021/11/25 17:13:33.674699, 2, pid=62409, effective(0, 0), real(0, 0)] ../../source3/rpc_client/cli_winreg_spoolss.c:1518(winreg_get_printer) winreg_get_printer: Could not open key SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\printers: WERR_FILE_NOT_FOUND [2021/11/25 17:13:33.677903, 1, pid=62409, effective(0, 0), real(0, 0)] ../../source3/printing/printer_list.c:234(printer_list_get_last_refresh) Failed to fetch record! Why would it be looking in SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\printers, it's not supposed to exist. All the printers are listed under \Print\Printers.
testparm -sv attached
Created attachment 17028 [details] testparm-sv.txt
I can add here, in 4.14.10 while using windows print manager on Windows 7. doesnt show anything anymore. No drivers, no printers.. 4.10.9 worked fine.
(In reply to Louis from comment #3) upgraded to 4.15.2 same results, no printers and no drivers seen.
Created attachment 17041 [details] log.spoolssd Looks like I forgot to attach the most important part of the log, spoolssd forks logs. Adding spoolssd, spoolssd.bq, and spoolssd.1. It has these clues: [2021/12/03 21:06:22.867682, 5, pid=2219013, effective(0, 0), real(0, 0)] ../../source3/printing/print_cups.c:338(cups_cache_reload_async) reloading cups printcap cache [2021/12/03 21:06:22.868085, 10, pid=2219013, effective(0, 0), real(0, 0)] ../../source3/printing/print_cups.c:138(cups_connect) connecting to cups server localhost:631 [2021/12/03 21:06:46.963182, 5, pid=2219011, effective(0, 0), real(0, 0)] ../../source3/printing/print_cups.c:532(cups_async_callback) cups_async_callback: callback received for printer data. fd = 13 [2021/12/03 21:06:46.963744, 0, pid=2219011, effective(0, 0), real(0, 0)] ../../source3/printing/print_cups.c:537(cups_async_callback) failed to recv pcap blob
Created attachment 17042 [details] log.spoolssd.bq
Created attachment 17043 [details] log.spoolssd.1 Also, I tried 4.13.14 and it's reproducible on that version too.
I think I know what the issue is. In my config I set `printcap name = cups`. If I replace it with the actual path to the printcap, like `printcap name = /var/run/cups/printcap`, Samba becomes able to see the list of printers. I thought it could be because my cupsd.conf doesn't have a Printcap explicitly configured, but I tried to add it and restart CUPS and Samba, and it didn't help. Looks like automatic detection of printcap doesn't work anymore, and we need to specify printcap name in smb.conf.
Thanks for the report and workaround details. It doesn't look like much has changed in this code path, although it does appear that a change to use the CUPS httpConnect2 API went in shortly after 4.11 . It'd be helpful if someone could test a revert of e7f0e858e00a76976c3d84c8808e9296254b42a5 to check whether it caused the regression - @Luis, would this be possible in your environment?
(In reply to David Disseldorp from comment #9) I would love to, only i need a text book guidance. i checked my 4.14.11 also, that shows it all correctly. So, im really bad with git.. sorry, i hope to get the time to learn git this year. what i did and hope is correct.. I did a git clone. Did a : git checkout e7f0e858e00a76976c3d84c8808e9296254b42a5 HEAD is now at e7f0e858e00 s3:printing: Use httpConnect2 from CUPS Then i did git reset --hard e7f0e858e00a76976c3d84c8808e9296254b42a5 git clean -f git checkout -b test-bz14919 So, from this point, whats next from this point? Go compile it and test it?
(In reply to Louis from comment #10) > (In reply to David Disseldorp from comment #9) > > I would love to, only i need a text book guidance. Thanks Louis! I'm happy to provide guidance :-) > i checked my 4.14.11 also, that shows it all correctly. > > So, im really bad with git.. sorry, i hope to get the time to learn git this > year. > what i did and hope is correct.. > > I did a git clone. > Did a : git checkout e7f0e858e00a76976c3d84c8808e9296254b42a5 > HEAD is now at e7f0e858e00 s3:printing: Use httpConnect2 from CUPS > > Then i did > git reset --hard e7f0e858e00a76976c3d84c8808e9296254b42a5 > git clean -f > > git checkout -b test-bz14919 > > So, from this point, whats next from this point? > Go compile it and test it? If it's a fresh clone then you shouldn't need "git clean", which is normally just used to trim untracked files and directories (e.g. after build) from the cloned source. The "git reset" is also unnecessary, as you'd already done a "git checkout" of the same commit. Anyhow, your "test-bz14919" branch should have the possible-regression (e7f0e858e) at the top, which you can verify by running "git log -1". It is indeed ready for compilation and testing. Please ensure that you compile alongside the CUPS development libraries. Your bin/config.log should indicate whether the httpConnect2() API is available. After testing and hopefully reproducing this bug, you can checkout the commit prior to the possible regression: "git checkout e7f0e858e00a76976c3d84c8808e9296254b42a5^ -b test-bz14919-before" (the trailing '^' is an alias for the commit before e7f0e858e) Then you're ready to compile and test again (hopefully seeing different behaviour). If compilation fails you could try a clean rebuild by running "git clean -fxd").
(In reply to David Disseldorp from comment #11) Thank, took a bit set it up for a from source compilation but its running. Office is closing up here, so i'll test tomorrow.
(In reply to Louis from comment #12) > (In reply to David Disseldorp from comment #11) > Thank, took a bit set it up for a from source compilation but its running. > Office is closing up here, so i'll test tomorrow. Thanks a lot for testing this, Louis. It's much appreciated!