Solving: samba registry with client programs

simo idra at
Tue Apr 17 13:08:35 MDT 2012

On Tue, 2012-04-17 at 20:52 +0200, Stef Walter wrote: 
> I posted earlier about this, but figured some background might be handy.
> I'm building an on demand DBus service which makes it simple to enroll a
> machine in an AD domain, set up domain logins, manage shares and so on.
> It would be called from gnome-control-center and other bits of UI.
> The samba registry is a really great fit for this, for reasons detailed
> below. But I ran into the problem that using the registry then prevents
> samba client programs (like smbclient) from working. They get an 'access
> denied' error when trying to load the config because registry.tdb is not
> readable.
> It has already been established that making registry.tdb world readable
> is a bad idea. So here are the various other options. I'd like to try
> option (3) unless that has problems, in which case option (4) seems like
> the best alternative.
> Option 1. Don't use the registry
>    Adding a file share by modifying smb.conf and restarting smbd
>    seems like it would disconnect clients. This would be really
>    broken behavior for desktop users or server admins using a
>    config tool.
>    In addition for machine generated config it's always awkward
>    and brittle to deal with modifying a text file: Locking issues,
>    user modifications, testing config etc... So registry config
>    is a nice to have for machine generated configuration, at least
>    for shares.
>    Seems like these are some of the main points of the samba registry
>    based config was to solve. Not sure how else to solve the problem
>    of kicking clients when reconfiguring smbd.
> Option 2. Have client programs ignore failures loading the registry
>    Client apps would just use smb.conf and not use the registry.
>    They would ignore failures to load the registry, and just use
>    the configuration available in smb.conf.
>    This works well if the registry is deployed mainly as a way to
>    configure shares, and much of the other stuff lives in smb.conf.
>    This only really makes sense with 'include = registry' in smb.conf.
>    I could create a patch which implements this.
> Option 3. Mirror config from the registry
>    As Volker suggested, on each commit to the config parts of the
>    registry, the registry config would be exported to a read-only
>    file in the "lock directory".
>    Client apps would detect an access failure when loading the
>    registry and silently include this file in their config
>    instead of using the registry.
>    I could try and create a patch which implement this.
> Option 4. Have a smb-client.conf
>    As Simo suggested, have clients use smb-client.conf when that file
>    is present. This would be instead of reading the smb.conf file and
>    thus the registry.
>    I could try and create a patch which implements this.
> Option 5. Use a daemon to read config
>    As Simo suggested there might be a daemon which runs and makes
>    the config available to the clients using RPC.
>    Seems resource intensive, and out of my current time and
>    capabilities.

Stef, FWIW, you do not need to code up a new daemon, running smbd would
suffice as it provides access to the registry RPC enpoint over NCACN_NP
or the new NCALRPC. But you would need to write some client logic to do
that and you would require smbd running.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list