[Samba] smbsrv_reply_printwrite not returning a response causing the print job to be truncated to 124 bytes

[Mateusz Mikołajczyk]

yes, I have read it. In fact, had it not been for the damned DOS client the
printing would have work flawlessly as well. windows machines are able to
print from the same printer - just not the DOS client. I suppose the reason
is that (as I've read in either samba wiki or manual pages) later versions
of the protocol switched to a different way of printing whereas the DOS
seems to be using the old LanMan printing (?).

again, I actually suspect that this could be a hack of some sort added on
the win xp implementation because that's the server that seems to be
sending the print file write response. if I'd need to write a patch and use
a locally-compiled version of samba, I'd also be happy with that because I
do understand that nobody should even be using this legacy function calls
in the first place, but my problem is that I don't know what I should write
in order for the function to resemble the old samba 3 behavior ;)

I didn't knew that ntvfs handler would not be used, I only started to
experiment with configuration options as I had a hunch that this had
something to do with sync / async and I basically searched manual page for
smb.conf for every mention of either 'DOS', 'legacy', 'sync' keywords and
tried to apply them as some of them were limited to a share.

I've also tried to use 'disable spoolss = yes' but then samba responds with
an error packet (code = 0x03 that is described by wireshark as 'Hardware
Error')

Could it be that I should simply revert to samba 3.0.3 instead of using the
upstream version ? I don't actually require any DC functionality at all, I
was just hoping that I could achieve the same functionality on the upstream
release via some 'magical' configuration switch :).

czw., 29 kwi 2021 o 13:11 Rowland penny via samba <samba at lists.samba.org>
napisał(a):

> On 29/04/2021 11:58, Mateusz Mikołajczyk via samba wrote:
> > I've also searched trough github and found that the commit that removed
> > those 0 bytes (if they are in fact what I believe they are - a response
> > packet) was 591669ba066cde377c0c14e3473f23b35530b4ba which was
> > called r24431: Convert the reply_printXX calls to the new API. Of course
> > that were the changes in source3 directory rather than source4, but it
> > could be what originated the changes in samba 4 as well - that's only my
> > guess
> >
>
> Samba is on gitlab now: https://gitlab.com/samba-team/samba
>
> You have 'ntvfs handler' in your smb.conf, this will not be used on a
> standalone server as it was only meant for the Samba AD DC where the
> 'samba' binary is run. It also requires the NTVFS file server, this is
> now only used for testing puposes.
>
> Have you read this:
> https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Print_Server
>
> Rowland
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>


-- 
pozdrawiam serdecznie,
Mateusz Mikołajczyk, a.k.a. toudi