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:
Shared-folder:
depends_on:
serviceapi:
condition: service_healthy
image: ambar/ambar-local-crawler
restart: always
networks:
- internal_network
expose:
- "8082"
environment:
- name=Shared-folder
- ignoreExtensions=.{exe,dll,rar,s,so}
- apiUrl=http://serviceapi:8081
user: crawler
volumes:
- /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:
[sssd]
services = nss, pam
config_file_version = 2
domains = MY.COMPANY.COM
[domain/MY.COMPANY.COM]
id_provider = ad
access_provider = ad
ad_gpo_map_interactive = +cron
dyndns_update_ptr=false
# 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 haveuse_fully_qualified_names = False
. Without this, you may be expected to use fully qualified names (e.g.[email protected]
). 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: [email protected]
). 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 youruse_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.