[Samba] libsmbclient help

Jeremy Allison jra at samba.org
Wed Jan 13 21:48:52 UTC 2021

On Wed, Jan 13, 2021 at 08:06:23PM +0800, 赵晶 via samba wrote:
>Hi Samba team,
>We're evaluating the use of libsmbclient API + smbclient utility
>combination to back up a CIFS/SMB share from a Linux box. There are some
>questions. Please help.
>1. There is no way to query Alternate Data Streams for a file in
>libsmbclient. So we use smbclient 'allinfo'.

Can you describe what API you'd like inside libsmbclient to
return a list of ADS (Alternate Data Streams) ? We have
the internal code to get this info, but don't currently
export it.

>*Is the output format of 'allinfo' guaranteed to be fixed (especially w.r.t
>the three stream lines below)?* We need to parse the stream names out of
>the allinfo result.
>smb: \> allinfo ads.txt
>altname: ads.txt
>create_time:    Mon Dec 14 08:32:07 AM 2020 EST
>access_time:    Mon Dec 14 08:32:18 AM 2020 EST
>write_time:     Mon Dec 14 08:33:22 AM 2020 EST
>change_time:    Mon Dec 21 03:20:05 AM 2020 EST
>attributes: A (20)
>stream: [::$DATA], 3 bytes
>stream: [:extra:$DATA], 8 bytes
>stream: [:extra2:$DATA], 9 bytes

Nothing in smbclient is "fixed" as an output format.
It's not a standardized utility. Having said that
we don't deliberately change or break things if
we can help it.

>2. We need to get security info (e.g, ACL, owner, groups, etc) of each
>file/folder. Right now we query them using smbc_getxattr() and parse the
>result. *Is the result format supposed to change (keywords as "OWNER:",
>"GROUPS:", "ACL:")*?
>ACL info of smb://jingcs2.testlab.commvault.com/share/ads.txt:

As above.

>3. *I don't find any API in libsmbclient to get reparse point info, e.g.,
>to query allocation ranges for a sparse file. Is there a way to archive

libsmbclient doesn't currently follow reparse points or
get the info. That's something we'll probably be working
on as part of the SMB2+UNIX extensions work as the plan
is to expose server-symlinks as reparse points there so
we'll need the code internally to support this.

>   Right now smbc_read() gets the file as a complete non-sparse file (so is
>smbclient's "get" command).

We have internal code to do this, but again it's not
exposed at the libsmbclient layer.

>4. We include libsmbclient.h and links to libsmbclient.so. *Is it good
>practice if we ship libsmbclient.so and its dependencies within our
>products or use the ones shipped in the client environment? If the latter
>case (don't ship ourselves), are the libsmbclient APIs (i.e., smbc_XXX)
>guaranteed to be compatible across different Samba versions?* (e.g.,
>older/newer versions of libsmbclient.so is installed on customer's clients,
>will any API break?)

Look at the major and minor version numbers of the library.
Major version number changes can break the ABI, minor versions

>5. *If we smbc_init() once and use different threads (which share the same
>smb context) to access/download the same share (of course different
>directories/files), is this supported in current model?*

No, this will eventually cause problems. This code is not
thread safe. Test using valgrind helgrind:


to fixure out what you might be able to get away with
if you're intent on doing this.

It sounds to me you might be better using and extending
the cli_XXX() internal layer of Samba and shipping your
own version rather than depending on the shipped libraries.

This cli_XXX() layer changes much more rapidly, but if
you have your own version you can then track these
changes with your own code.

NOTE!!!! cli_XXX() is *NOT* a publicly supported ABI and we
don't intend for it to be so, but if you want to
build solutions on top of it you can always keep
a local code branch.

Also note the licensing - libsmbclient and cli_XXX
are both GPLv3 - so consult your lawyers to understand
your responsibilities here. Anything that links with
them needs to be under a GPLv3-compatible license.

I'm happy to work with you to look over and advise
if you have code changes you'd like to get upstream
into Samba to help it work better for your needs !



More information about the samba mailing list