On Fri, Jan 01, 2021 at 09:49:06PM -0600, Steve French wrote:
I exported the /scratch directory with smb.conf configured as [scratch] comment = scratch share for testing browseable = yes path = /scratch guest ok = yes read only = no ea support = yes create mask = 0777 directory mask = 0777 vfs objects = acl_xattr map acl inherit = yes strict allocate = yes map acl inherit = yes mangled names = no Connecting with smbclient and doing a simple ls causes the disconnect: $ smbclient --version Version 4.12.5-Ubuntu $ smbclient //localhost/scratch -U testuser Enter SAMBA\testuser's password: Try "help" to get a list of possible commands. smb: \> ls . D 0 Fri Jan 1 21:19:52 2021 .. D 0 Thu Dec 31 21:42:28 2020 rsvd-chars D 0 Fri Jan 1 09:14:04 2021 file-?-question N 0 Fri Jan 1 21:19:42 2021 is_bad_finfo_name: bad finfo->name NT_STATUS_INVALID_NETWORK_RESPONSE listing \* smb: \> SMBecho failed (NT_STATUS_CONNECTION_DISCONNECTED). The connection is disconnected now
Well of course it disconnects. You set "mangled names = no" So the server returns the bad name. The smbclient library notices the server is trying to screw with it by sending invalid Windows names and disconnects to protect itself. This is by design. There is a *REASON* mangled names = yes is the default. Otherwise you can't see valid server filenames that contain : \ etc. etc. from a Windows client. Even a file names AUX: has to be mangled. "mangled names = no" is only useful for a pre-cleaned exported file system which you can guarantee contains only Windows-compatible names. This is not a bug, it's working as designed to protect the client code. There was a CVE where libsmbclient might pass up names containing a '/' to the calling code (not that they can exist on disk, but a malicious server could send them) which might then treat it as a path separator.
