User directories created by cli cron not writable for web server, HTTP 500 when trying to login

Nextcloud version (eg, 20.0.5): 20.0.14
Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04
Apache or nginx version (eg, Apache 2.4.25): 2.4.41
PHP version (eg, 7.4): 7.4

The issue you are facing:
Nextcloud is owned by a linux user nextcloud. It has rw(x) permission on everything nextcloud related.
The user is in the (primary) group www-data.
The group (which equals the one the apache/php process is running in) only has write permissions to data that actually has to be writable by it, i.e. temp files, cache, uploads, etc.
Config.php for example is also not writable by the apache process.

All of this is common knowledge for a secure web service setup and works nicely so far.

Updates are performed via occ on the commandline as user nextcloud.

However, I face a strange problem not only (see update) with LDAP/AD users.
Their user directories /home/nextcloud/nextcloud-data/<user-dir> get created as nextcloud:www-data with mode 755 during some cron run (at least their ctime always coincides with my cron execution times) even before the user’s first login.
After this has happened, logging in an LDAP-authenticated use (or a normal user, see update) therefore does not work, as I get an HTTP 500 as obviously the apache process cannot create the files nor the cache directory.

If I just delete the user’s directory and login with it, the directory gets created successfully with www-data:www-data and everything works out as it should.

Is there some kind of prepopulation done by the cron job? If it is, why, and can I change it to use the correct umask or make it quit doing it as it seems unnecessary anyway?

Does anyone else face this problem?
Or does everyone else let the apache user own and write everything and run cli cron with it as well?

I guess this is a bug, but I want to rule out misconfiguration before I file one.

Steps to replicate it:

  1. Setup permissions as mentioned above (nextcloud:www-data) for the whole installation.
  2. Setup LDAP auth (does not seem to be necessary, see update)
  3. Wait some time with the cli cron job configured. I don’t know when this happens, manually triggering the cron job on the cli does not create the empty user directories at once…
  4. Login with (an LDAP or a normal; see update) user not logged in before
  5. Get HTTP 500

The output of your Nextcloud log in Admin > Logging:

{"reqId":"SSfxGfG3Aok1faLcQmFL","level":3,"time":"2021-11-17T09:26:15+00:00","remoteAddr":"x.x.x.x","user":"user.name","app":"PHP","method":"POST","url":"/login","message":{"Exception":"Error","Message":"opendir(/home/nextcloud/nextcloud-data/user.name/cache): failed to open dir: No such file or directory at /var/www/nextcloud.domain/lib/private/Files/Storage/Local.php#136","Code":0,"Trace":[{"function":"onError","class":"OC\\Log\\ErrorHandler","type":"::"},{"file":"/var/www/nextcloud.domain/lib/private/Files/Storage/Local.php","line":136,"function":"opendir"}

Nothing else happening regarding the cron run, even if I set the log level to debug.

config.php:

<?php
$CONFIG = array (
  'config_is_read_only' => 'true',
  'instanceid' => 'xx',
  'passwordsalt' => 'xx',
  'secret' => 'xx',
  'trusted_domains' =>
  array (
    0 => 'nextcloud.domain',
  ),
  'datadirectory' => '/home/nextcloud/nextcloud-data/',
  'overwrite.cli.url' => 'https://nextcloud.domain',
  'dbtype' => 'mysql',
  'version' => '20.0.14.1',
  'dbname' => 'nextcloud',
  'dbhost' => 'dbserver:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => false,
  'dbuser' => 'nextcloud',
  'dbpassword' => 'xx',
  'installed' => true,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'filelocking.enabled' => 'true',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => 'redisserver',
    'port' => 6379,
    'timeout' => 0.0,
  ),
  'mail_from_address' => 'nextcloud',
  'mail_smtpmode' => 'smtp',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_domain' => 'nextcloud.domain',
  'ldapIgnoreNamingRules' => false,
  'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory',
  'log_rotate_size' => 104857600,
  'loglevel' => 1,
  'logfile' => '/home/nextcloud/nextcloud.log',
  'logfilemode' => 432,
  'mail_smtphost' => 'mail.nextcloud.domain',
  'mail_smtpport' => '25',
  'maintenance' => false,
  'updater.release.channel' => 'stable',
  'trashbin_retention_obligation' => 'auto, 14',
  'mail_sendmailmode' => 'smtp',
  'app_install_overwrite' =>
  array (
    0 => 'impersonate',
    1 => 'spreed',
    2 => 'files_accesscontrol',
    3 => 'quota_warning',
    4 => 'richdocuments',
  ),
  'encryption.legacy_format_support' => true,
  'encryption.key_storage_migrated' => false,
  'defaultapp' => 'files',
);

The same is valid for NC21, no improvement yet since the update.

Took a closer look now. It happens with non-LDAP users as well, so this can be ruled out I guess. Changed the topic accordingly.