SSSD fails to start with error – File ownership and permissions check failed

by Albert

If SSSD fails to start with “File ownership and permissions check failed”, first check access to /etc/sssd/sssd.conf and any configuration snippets. SSSD configuration can contain authentication secrets, so restrictive permissions matter.

For root-run installations whose distribution documentation requires root:root ownership and mode 0600, the repair is chown root:root /etc/sssd/sssd.conf followed by chmod 600 /etc/sssd/sssd.conf. Confirm your installed package’s requirements below before applying these commands.

1. Confirm the error and your SSSD version

Run these checks with sudo or from a root shell. Keep an existing administrative session open while troubleshooting authentication.

cat /etc/os-release
sssd --version
sudo systemctl status sssd --no-pager -l
sudo journalctl -u sssd -b -n 80 --no-pager

The specific permission error may appear in the journal or /var/log/sssd/sssd.log. A generic service-start failure alone does not identify the cause. Representative messages include the following. Numeric error codes can differ between versions.

Permission check on config file failed.
Cannot convert INI to LDIF: File ownership and permissions check failed
ConfDB initialization has failed
SSSD couldn't load the configuration database.

Older logs can also show status=4/NOPERMISSION and Start request repeated too quickly. Diagnose the earlier configuration error before retrying the service.

2. Inspect configuration ownership and permissions

sudo stat -c '%U:%G %a %n' /etc/sssd/sssd.conf
sudo ls -ld /etc/sssd /etc/sssd/conf.d
sudo find /etc/sssd/conf.d -maxdepth 1 -type f -name '*.conf' -exec stat -c '%U:%G %a %n' {} +

If the snippets directory does not exist, the last two commands may report that path as missing. Check each existing .conf snippet because an individual file can fail the access check even when the main file is correct.

Check the installed manual and service configuration to identify the ownership model used by your distribution.

man sssd.conf
sudo systemctl cat sssd.service

Version guidance. Many older Enterprise Linux installations use root-owned configuration with mode 0600. Newer packages can run SSSD as an unprivileged user and use different ownership rules. For example, upstream SSSD 2.10.2 packaging includes root:sssd ownership and mode 0640. Distribution packaging and backports can differ, so follow the installed package’s documentation. The upstream details are recorded in the SSSD 2.10.2 release notes.

3. Repair permissions for a root-run installation

Use the following commands only when your installed package requires root:root and 0600 for the main configuration file. They require administrative privileges.

sudo chown root:root /etc/sssd/sssd.conf
sudo chmod 600 /etc/sssd/sssd.conf
sudo stat -c '%U:%G %a %n' /etc/sssd/sssd.conf

The final command should report root:root 600 /etc/sssd/sssd.conf for this ownership model. Apply the package-required permissions to any snippet identified as failing validation. Check individual files before changing them and keep configuration files inaccessible to other users.

4. Validate the configuration and verify recovery

If sssctl is available, check configuration syntax and access before restarting. It is commonly supplied by the distribution’s sssd-tools package.

sudo sssctl config-check

Resolve reported validation errors and configuration-merging messages, including rejected snippets. This check does not prove that the identity provider is reachable or that authentication will succeed. See Red Hat’s SSSD configuration-validation documentation for an example.

After validation succeeds, restart SSSD and inspect its state.

sudo systemctl restart sssd
sudo systemctl is-active sssd
sudo systemctl status sssd --no-pager -l
sudo journalctl -u sssd -b -n 50 --no-pager

Look for active and check the latest timestamps for fresh errors. If systemd still reports a start-limit failure after you correct the underlying issue, run sudo systemctl reset-failed sssd and retry the restart. Verify a known directory user with id '[email protected]', substituting your actual username, and test the required login method.

5. If SSSD still fails to start

  • Check every loaded snippet and any remaining syntax or configuration-merging errors.
  • If permissions match the installed documentation, inspect parent-directory access, ACLs, and SELinux denial logs. Diagnose the specific access failure before changing security settings.
  • Use detailed SSSD logging only when the existing logs are insufficient. Record the previous logging configuration before changing debug_level, then restore it after troubleshooting. Debug logs can contain sensitive identity information.

For additional log collection and troubleshooting steps, consult the official SSSD troubleshooting guide.

Leave a Reply