I recently replaced a SuSE Enterprise Linux SLES-9sp4 with SLES-11sp1 machine and after copying the share definitions from smb.conf to the new machine, I observed strange errors when trying "net view \\newmachine" from Windows (while accessing files on the shares worked without problem): System error 1745 has occurred The procedure number is out of range. A similar error was reported from "smblclient -N -L newmachine" after a significant delay. _After_ knowing what the problem is, locating the relevant information in the debug logfiles is easier: [2012/06/12 06:17:46, 3] lib/charcnv.c:242(convert_string_internal) convert_string_internal: Conversion error: Incomplete multibyte sequence(ür Protokolle des Nachtmakes) [2012/06/12 06:17:46, 1] ../librpc/ndr/ndr.c:403(ndr_push_error) ndr_push_error(5): Bad character conversion [2012/06/12 06:17:46, 0] rpc_server/srv_pipe.c:2332(api_rpcTNP) api_rpcTNP: \srvsvc: SRVSVC_NETSHAREENUMALL failed. It would be preferable for smbd/nmbd (and smbstatus) to check for such problems - and report a meaningful error message themselves and upfront - avoid to make clients produce strange error messages -Martin
Re-assigning to Jeremy. Jeremy, please feel free to re-assign to someone else. Thanks!
Can you upload your smb.conf file please ? Thanks. Jeremy.
From: "Rex, Martin" <martin.rex@sap.com> To: "'samba-bugs@samba.org'" <samba-bugs@samba.org> Subject: RE: [Bug 8993] ISO8859-1 char in Share comment causes nmbd (3.4.3 on SLES-11sp1) malfunction > > Can you upload your smb.conf file please ? Not possible and not necessary. As originally describe. the error occurs with an iso-latin1-char appearing in comment string of a share in the smb.conf file, It might be due to SLES-11 poor choice of a default locale (UTF8) rather than ISO-8859-1 (the standard since 1992). Part of the comment appears in the quoted error message, it was a lower case umlaut "u" between a lower case 'f' and a lower case 'r'. ie a character sequence of 0x66 0xfc 0x72 within the comment string of a share. The error message in the logfile suggests that some codepage conversion function breaks on the "incomplete" UTF8 codepoint, however the server coding seems to not handle this situation sensibly, because it results in random malfunction rather than a comprehensible error message about the codepage conversion error.
(In reply to comment #3) > From: "Rex, Martin" <martin.rex@sap.com> > To: "'samba-bugs@samba.org'" <samba-bugs@samba.org> > Subject: RE: [Bug 8993] ISO8859-1 char in Share comment causes nmbd (3.4.3 > on SLES-11sp1) malfunction > > > > > Can you upload your smb.conf file please ? > > Not possible and not necessary. > > As originally describe. the error occurs with an iso-latin1-char > appearing in comment string of a share in the smb.conf file, > It might be due to SLES-11 poor choice of a default locale (UTF8) > rather than ISO-8859-1 (the standard since 1992). > > Part of the comment appears in the quoted error message, > it was a lower case umlaut "u" between a lower case 'f' > and a lower case 'r'. ie a character sequence of > 0x66 0xfc 0x72 within the comment string of a share. Sorry, with the refusal to give an example here in a form that is easy to reproduce I don't think there will be anybody to work on this for free. It does not have to be your original smb.conf, it must be something we can download and "just use". For paid support, please find someone from http://www.samba.org/samba/support/ With best regards, Volker Lendecke
creating an smb.conf to repro this effect should be trivial from the information initially supplied (which names the constraints and includes the relevant error messages from smbd.log that indicate which part of samba is buggy). The problem is related to samba's "unix charset" configuration parameter on the one hand (which defaults to UTF8), and the shortcoming to not verify string parameter encoding (such as share comments) when reading smb.conf, but rather blindly put them into memory structures and later fail on character conversions. The code locations indicated by the quoted smbd.log entries refer to: (1) samba-3.4.3/source3/librpc/ndr/ndr_string.c:339(ndr_push_string) (2) samba-3.4.3/source3/rpc_server/srv_pipe.c:2329(api_rpcTNP) and indicate that (1) the character conversion causes an error during an attempt to send a string (probably the share comment) over the network, which causes the entire RPC call to fail (2). Since I've never looked at samba source before, I don't know the coding between (1) and (2), and whether there exists code below (2) that will cause a comprehensible error message to be produce for the failed RPC call. But really, (1) and (2) are _much_ too late down the road to deal with a mismatch of the "unix codepage" that smbd assumes when parsing smb.conf and the invalid character encodings of parameter values within smb.conf. Any kind of such a mismatch should be dealt with (and either reported&aborted or worked around) immediately when parsing smb.conf. -Martin
Well the problem is we just read a stream of bytes when parsing smb.conf parameters and plonk them into a C string (nul terminated byte array). It's only when we try and do something with it we need to do a transform (in this case it's probably utf8 -> utf16). That's the point we find out it's bad, but that depends on the transform. To fix this the way you want we'd have to add a validator, based on current charset, into the smb.conf parser. Do-able, but will take me time to look at, and it's all a bit much to fix something that the admin really should take care of themselves. All UNIXes and Linux distros have standardized on utf8 as default locale, as it's the only sane way to deal with multi-lingual input without restricting them to a regional character set encoding. Jeremy.