When you would not use a smb.conf and edit under Windows
Starting with Samba version 3.2.0, the capability to store Samba
configuration in the registry is available. The configuration is stored
in the registry key HKLM\Software\Samba\smbconf. There are two levels
of registry configuration:
1. Share definitions stored in registry are used. This is triggered by
setting the global parameter registry shares to “yes” in smb.conf.
The registry shares are loaded not at startup but on demand at
runtime by smbd. Shares defined in smb.conf take priority over
shares of the same name defined in registry.
2. Global smb.conf options stored in registry are used. This can be
activated in two different ways:
Firstly, a registry only configuration is triggered by setting
config backend = registry in the [global] section of smb.conf. This
resets everything that has been read from config files to this
point and reads the content of the global configuration section
from the registry. This is the recommended method of using registry
Secondly, a mixed configuration can be activated by a special new
meaning of the parameter include = registry in the [global] section
of smb.conf. This reads the global options from registry with the
same priorities as for an include of a text file. This may be
especially useful in cases where an initial configuration is needed
to access the registry.
Activation of global registry options automatically activates
registry shares. So in the registry only case, shares are loaded on
Note: To make registry-based configurations foolproof at least to a
certain extent, the use of lock directory and config backend inside the
registry configuration has been disabled: Especially by changing the
lock directory inside the registry configuration, one would create a
broken setup where the daemons do not see the configuration they loaded
once it is active.
The registry configuration can be accessed with tools like regedit or
net (rpc) registry in the key HKLM\Software\Samba\smbconf. More
conveniently, the conf subcommand of the net(8) utility offers a
dedicated interface to read and write the registry based configuration
locally, i.e. directly accessing the database file, circumventing the
good news. You are using Linux with Kernel 4.13 so that can happend that you get a mount error by mounting a smb share. Why happend this?
You are mounting a SMB 1 share.
Since Kernel 4.13 it will be tried to mount with version 3.
See git commit
You should use SMB in Version 2.1 or higher
SMB 1.0 is broken, see blog post from Microsoft
Please look at this side
I will try this at my own enviroment and when it works, so i will some posts about this
It´s not very easy to understand with the ce edition.
Here is my working config with gitlab ce 10
Before you edit your gitlab.rb please make a backup
cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb_org
Please remember your are editing a yaml file, yaml files are sensitiv for spaces etc
gitlab_rails[‘ldap_enabled’] = true
gitlab_rails[‘ldap_servers’] = YAML.load <<-EOS # remember to close this block with ‘EOS’ below
port: 389 #Change to 636 if using LDAPS
method: ‘plain’ # Change to “tls” if using LDAPS
uid: ‘sAMAccountName’ # Don’t change this
# Optional: the next line specifies that only members of the user group “gitlab-users” can authenticate to Gitlab:
Attention i have tried a lots of user_filter examples there variants are working for me.
Check your LDAP Access and Group Members
Most found there