0 votes
Last night Samba was updated to 4.10.16-15 in my Community machine. Today I realize that my windows 10 clients cannot reach flexshares or print to the printers connected to the cups server. I think something is broken with Samba.

I am using "simple networking"

In my Windows 10 client I get "RPC protocol error" message whenever I try to reach a flexshare or try to print. In the samba log I get messages like this for each attempt from my Windows client:
[2021/06/23 13:01:07.222542,  1] ../../librpc/ndr/ndr.c:641(ndr_push_error)
ndr_push_error(5): Bad character push conversion with flags 0x80080040

[2021/06/23 13:01:07.233213, 1] ../../librpc/ndr/ndr.c:641(ndr_push_error)
ndr_push_error(5): Bad character push conversion with flags 0x80040

[2021/06/23 13:01:07.233234, 0] ../../source3/rpc_server/srv_pipe.c:1555(api_rpcTNP)
api_rpcTNP: spoolss: SPOOLSS_GETPRINTER failed.

[2021/06/23 14:37:53.842563, 1] ../../librpc/ndr/ndr.c:641(ndr_push_error)
ndr_push_error(5): Bad character conversion

[2021/06/23 14:37:53.842613, 0] ../../source3/rpc_server/srv_pipe.c:1555(api_rpcTNP)
api_rpcTNP: srvsvc: SRVSVC_NETSHAREENUMALL failed.

The "Bad character push conversion with flags" looks "interesting". Note that my Win 10 clients uses Swedish setup (but my flexshares and printers use the normal english alphabet only)

Anyone that experience this too or know what to do?
Wednesday, June 23 2021, 12:55 PM
Share this post:
Responses (5)
  • Accepted Answer

    Thursday, June 24 2021, 01:16 PM - #Permalink
    0 votes
    This is whacky. If you get round to troubleshooting again, it may be worth trying the Samba mailing list as well.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 24 2021, 12:04 PM - #Permalink
    0 votes
    Thanks Nick for testing, the problem is on a more fundamental level so if it works with flexshare it should not be a problem with printer sharing.

    I did some more testing, and now I am more confused than ever... It could be that the problem is specific to my machine/setup only:

    1. I did update my development machine as well. ( It did have "server max protocol = NT1" in the smb.conf file both before and after the update. ) No problem to connect to it from my Windows 10 clients before or after the update.

    So maybe something bad have happened to my normal server that has been running ClearOS 7 24/7 since it came out some years ago without me changing any samba configuration for more than 2 years or just about anything else with it either...

    2. So I decided to play a little bit more with my normal server that experienced this update problem.
    a. First I verified that file and print sharing still worked from my Win10 client (with protocol = SMB3 in the smb.conf file)
    b. I removed the protocol = smb3 and saved the file. -> I could see in the Win10 client that my server disappeared a few seconds (I think I have read that Samba automatically reconfigure itself whenever smb.conf is changed) -> I could still connect to the flexshares from the Win10 client
    c. Then I typed "systemctl restart smb" -> Now I could not connect to the flexshares anymore
    d. I entered the "protocol = smb3" line again into smb.conf and saved the file -> In Win 10 client I saw the server disappear and come back -> Still got "RPC error" when trying to connect
    e. I restarted the smb.service again, and now I could connect again.

    Now I was pretty confident that the line "protocol = smb3" was the magic thing "solving" my issue for some strange reason. As you say, this line in practice means that it is using the same value as default (without the line)...

    However, I did one more test (2b - 2e above), however it was no longer possible to connect to my server from my Win10 client. I repeated these steps probably 20-30 times without any success. I even tried to change "smb3" to "smb3_11", "smb3_02", "smb2", "NT1". For all protocol versions except smb3 and smb3_11 my Win10 client complained that it could not reach the server, but for smb3 and smb3_11 I got the RPC error.

    So clearly(?) the protocol=smb3 line was not the magic solution. But for some reason it worked for a while...

    Thinking about the error about "bad character" I started to think it could be a character set problem (remember my Win 10 clients are running Swedish setup). So instead of the protocol = smb3 line I entered (also under the global section): "unix charset = UTF-8" in smb.conf file, saved it and restarted the smb.service -> Now I could access the flexshare from my Win10 client again!

    Given my previous experience I had to undo/re-enter this line again -> Result: Removing the line prevented Win10 client to connect, Adding the "charset" line back did however not work.... So the root cause is probably not a "charset" problem.

    So, my conclusion now is that I must have some problem in my setup/config somewhere and this smb.conf editing & restarting smb.service is just triggering it somehow. It seems, apart from the first couple of rounds with the protocol line, that when I save something "new" in smb.conf that has not been there before then it works until I restart the smb.service next time. Now, I do not have time to trouble shoot for quite some time and I needed flexshare and my printer sharing to work again, so for now I have entered the line "dos charset = cp865" in smb.conf and restarted smb.conf. Now I am fine until next restart and then I will likely need to come up with a new parameter to set in smb.conf ;)

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 24 2021, 10:12 AM - #Permalink
    0 votes
    I've upgraded a test box which is normally off and the Flexshare worked first time. Like you I have no "protocol" or "server min protocol" lines.

    I don't use the printer server anywhere and have no means of testing it.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 23 2021, 04:42 PM - #Permalink
    0 votes
    Well found. That is frightening for a minor update and I'll have to check it out if I can. I thought samba negotiated the highest protocol possible anyway.

    If anyone else has this problem please can you add a "me too" message in this thread so I know it is not just Fredrik.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 23 2021, 01:57 PM - #Permalink
    0 votes
    Ok, this is what I did that seems to work:

    Add the following line under the [global] section in /etc/samba/smb.conf

    protocol = SMB3

    I had no other "protocol" line in the smb.conf file before, and before the update of Samba I was on 4.10.16-13 and it worked fine. For some reason it seems to be neccessary to set the protocol level now...
    The reply is currently minimized Show
Your Reply