LDAP user share by link issue: OC\User\NoUserException: user@example.com is not a valid user anymore

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version: 15.0.4
Operating system and version : Ubuntu 16.0.4
Nginx version: 1.10.3
PHP version:7.2.14

The issue you are facing:
LDAP user can successfully authenticate, upload and share files to other ldap, internal users and by share link. However when the ldap user logoff and if any one try to access the share file via public link following error appears in web page. The shared files are only accessible to anyone as long as the file owner is logged in. This happens after LDAP/AD Integration apps settings Cache-Time-To Live expires.

Internal Server Error

The server was unable to complete your request.

If this happens again, please send the technical details below to the server administrator.

More details can be found in the server log.

Technical details
Remote Address:
Request ID: OTWxBlIHEEHPR4bqZ1GR

Is this the first time you’ve seen this error? (Y/N):Yes

The output of your Nextcloud log in Admin > Logging:

[no app in context] Error: OC\User\NoUserException: user@example.com is not a valid user anymore at <<closure>>

 0. <<closure>>
    getHome("user@example.com")
 1. /appfiles/nextcloud/apps/user_ldap/lib/User_Proxy.php line 81
    call_user_func_array([OCA\User_LDAP\User_LDAP {},"getHome"], ["user@example.com"])
 2. /appfiles/nextcloud/apps/user_ldap/lib/Proxy.php line 152
    walkBackends("user@example.com", "getHome", ["user@example.com"])
 3. /appfiles/nextcloud/apps/user_ldap/lib/User_Proxy.php line 227
    handleRequest("user@example.com", "getHome", ["user@example.com"])
 4. /appfiles/nextcloud/lib/private/User/User.php line 282
    getHome("user@example.com")
 5. /appfiles/nextcloud/lib/private/Files/Storage/Home.php line 53
    getHome()
 6. /appfiles/nextcloud/lib/private/Files/Mount/MountPoint.php line 147
    __construct({user: OC\User\User {}})
 7. /appfiles/nextcloud/lib/private/Files/Mount/MountPoint.php line 172
    createStorage()
 8. /appfiles/nextcloud/lib/private/Files/Filesystem.php line 321
    getStorage()
 9. /appfiles/nextcloud/lib/private/Files/Filesystem.php line 443
    getStorage("user@example.com")
10. /appfiles/nextcloud/lib/private/Files/Filesystem.php line 376
    initMountPoints("user@example.com")
11. /appfiles/nextcloud/lib/private/legacy/util.php line 308
    init("user@example.com", "/user@example.com/files")
12. /appfiles/nextcloud/apps/files_trashbin/lib/BackgroundJob/ExpireTrash.php line 99
    setupFS("user@example.com")
13. /appfiles/nextcloud/apps/files_trashbin/lib/BackgroundJob/ExpireTrash.php line 82
    setupFS("user@example.com")
14. /appfiles/nextcloud/lib/private/User/Manager.php line 535
    OCA\Files_Trashbin\BackgroundJob\{closure}("*** sensitive parameters replaced ***")
15. /appfiles/nextcloud/apps/files_trashbin/lib/BackgroundJob/ExpireTrash.php line 87
    callForSeenUsers(Closure {})
16. /appfiles/nextcloud/lib/private/BackgroundJob/Job.php line 61
    run(null)
17. /appfiles/nextcloud/lib/private/BackgroundJob/TimedJob.php line 55
    execute(OC\BackgroundJob\JobList {}, OC\Log {})
18. /appfiles/nextcloud/cron.php line 123
    execute(OC\BackgroundJob\JobList {}, OC\Log {})

at 2019-02-19T08:00:02+00:00

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'oc2y456onfyht',
  'passwordsalt' => 'password',
  'secret' => 'secrect password',
  'trusted_domains' =>
  array (
    0 => 'cloud.example.com',
  ),
  'datadirectory' => '/opt/nxtfiles/data',
  'overwrite.cli.url' => 'https://cloud.example.com',
  'dbtype' => 'mysql',
  'version' => '15.0.4.0',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud_user',
  'dbpassword' => '<removed sensitive info>',
  'installed' => true,
  'trashbin_retention_obligation' => '30, 31',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'filelocking.enabled' => 'true',
  'redis' =>
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
    'timeout' => 0.0,
  ),
  'ldapIgnoreNamingRules' => false,
  'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'updater.release.channel' => 'stable',
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'tls',
'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'noreply',
  'mail_domain' => '<removed sensitive info>',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtphost' => '<removed sensitive info>',
  'mail_smtpport' => '587',
  'mail_smtpname' => '<removed sensitive info>',
  'mail_smtppassword' => '<removed sensitive info>',
);



Fixed by changing LDAP filter:+1:

Hi, I’m having this exact problem. Can you explain me to what you have changed in the filter?

Many thanks!

Hi, As we do not want all our ldap users to access nextcloud, the pager field was used for filtering. Ours resolved by changing LDAP filter settings in the LDAP/AD intergration >Users tab
from
&(objectClass=inetOrgPerson)(pager=ncUser)
to
just (pager=ncUser)
and on Login Attributes tab > selected attributes from the Other attributes drop down. The filter automatically created based on my selection.

Thanks very much for you answer!
I simplified a lot the filter keeping, similarly to what you did, just one condition but, unfortunately, still getting the same behavior.
My PHP and Nextcloud versions are practically the same as yours (7.2.16 and 15.0.5 respectively).

I’ve noticed also that the problem temporarily goes away if you login as admin and just list the users, so it must be a problem due to refreshing the data from LDAP but there is apparently no way to refresh it periodically with a cron job, for example.

Sorry to hear that it didn’t helped :roll_eyes: I too noticed same that listing users from admin temporary resolves issue until Cache-Time-To-Live expires which is by default set to 600 seconds. Its surely something with your LDAP filter.
Are you able to test successfully verify settings and count users and Test Login name ?

Yes, everything works perfectly including reading the groups and membership. Is definitely just a problem with Cache TTL. Now I circumvented it by setting it very high, 20 days! :roll_eyes:

What baffles me is reading the documentation at https://docs.nextcloud.com/server/15/admin_manual/configuration_user/user_auth_ldap.html where is written:

"The Cache Time-To-Live is related to each single request. After a cache entry expires there is no automatic trigger for re-populating the information, as the cache is populated only by new requests, for example by opening the User administration page, or searching in a sharing dialog.

There is one trigger which is automatically triggered by a certain background job which keeps the user-group-mappings up-to-date, and always in cache."

What is this “certain background job”? I’ve checked and it seems that running cron.php doesn’t refreshes the LDAP cache.

Absolutely no idea what does that mean by “certain background job” . Since Cache TTL is set to 20 days Its worth checking if a disabled LDAP user can still login or not.

Yes, in fact if I disable a user it is not reflected in Nextcloud. The trick I need to do is to go and change the Cache TTL to any value and then back again to 20 days, this way the cache gets cleared. Finally I go in the user list to force rebuilding of the cache.
This is tricky but still less than explaining to users the server error since this is happening in a production environment…

I keep investigating this in a testing environment, if I come to something I will make sure to post in this topic. Really thanks for your willing to help :+1: