I am running several Samba-shares on a dedicated Debian 9.6 machine joined to an AD-domain (Zentyal with SMB 4).

I am using a pretty straight-forward SSSD installation that has so far worked out perfectly for our needs.

I want to set Ambar up so that the various domain users could search documents on the aforementioned Samba-shares. However, I only want Ambar to crawl "public" documents, and nothing from private/"management" folders.

I've changed the docker-compose.yml file so that Docker will spawn the containers it needs as the user crawler, but when I run docker-compose up -d I get the following error:

ERROR: for Shared-folder Cannot start service Shared-folder: linux spec user: unable to find user crawler: no matching entries in passwd file

Editing the /etc/passwd file manually does not help here. I still get the same error.

This is how the relevant docker-compose.yml configuration looks like:

      condition: service_healthy
  image: ambar/ambar-local-crawler
  restart: always
    - internal_network
    - "8082"
    - name=Shared-folder
    - ignoreExtensions=.{exe,dll,rar,s,so}
    - apiUrl=http://serviceapi:8081
  user: crawler
    - /shared/Shared-folder:/usr/data

Please observe that if I remove the line user: crawler, everything works as expected (and root crawls all of my documents).

Here is my /etc/sssd/sssd.conf-file:

services = nss, pam
config_file_version = 2
domains = MY.COMPANY.COM

id_provider = ad
access_provider = ad
ad_gpo_map_interactive = +cron

# Use this if users are being logged in at /.
# This example specifies /home/DOMAIN-FQDN/user as $HOME.  Use with pam_mkhomedir.so
override_homedir = /home/%u
ldap_idmap_autorid_compat = True

And here's my /etc/pam.d/common-session:

# /etc/pam.d/common-session - session-related modules common to all services
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive).
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
session [default=1]                     pam_permit.so
# here's the fallback if no module succeeds
session requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required        pam_unix.so
session required        pam_mkhomedir.so skel=/etc/skel/ umask=0066
session optional                        pam_winbind.so
session optional                        pam_sss.so
session optional        pam_systemd.so
# end of pam-auth-update config

Please let me know if any configs would be helpful! My guess is that smb.conf is not that relevant in this case, and that there might be some way to tell Docker to just trust PAM?


The domain configuration in sssd.conf doesn't have use_fully_qualified_names = False. Without this, you may be expected to use fully qualified names (e.g. crawler@MY.COMPANY.COM). This is not strictly necessary to solve your problem but I find it useful if the machine is only referencing one domain. Alternatively:

  • You might try specifying the fully qualified name for the user in docker-compose.yaml (i.e. user: crawler@MY.COMPANY.COM). I have not tried this so I can't confirm it works as expected.

  • You could use the uid of the user instead of the name. This is the method I use so I can confirm it works just fine. You can retrieve the uid by running id <username> (making sure you use the format corresponding to your use_fully_qualified_names setting).

In any case, if you can't retrieve the uid of your user by running id <username> then your issue likely lies with your SSSD configuration rather than the docker configuration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.