-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LDAP-Users can not login & user folder will not be created on filesystem data directory #24423
Comments
Thanks for the detailed report. You might want to try upgrading to 9.0.2 that just got released, in case it helps. @blizzz @icewind1991 any idea about these errors ? |
Upgrading to 9.0.2 did not fix the problem for me.
|
I'm testing the upgrade of an owncloud 7 installation to 9, up until 8.2.x the ldap backend worked fine, but after upgrading to 9 (9.0.2.2) I get an empty page while logging an ldap user in and the following error message in the log. My local admin user works as expected.
|
Is that for any LDAP user ? Or is that LDAP user receiving shares ? |
Oh, I only copied data for some users, but I found out that it is only for my user. My user is receiving a share from a user that I didn't copy yet. I'll copy that users data tomorrow and check back with you. But sorry for the fuss, it isn't a general ldap problem. |
It might be an issue with invalid shares, which ownCloud is supposed to silently ignore. Some might get cleant up later when running cron, if applicable. Would be good to find out what kind of share it is and how it got into that state. |
We're experiencing an issue that is likely the same underlying bug: Error message Our environment is similar: owncloud 8 updated to 9, LDAP users. |
All right, I checked in the database, I've got one "incoming" share ( Thanks for the quick responses. |
We see the same problems with 9.0.2 and OpenLDAP. The error occurs reproducibly when a new LDAP user has not yet logged in to Owncloud, but receives a share. The latter can happen either directly, if someone shares a folder with the new LDAP user, or indirectly by group membership. We mostly see the group membership situation. After the error has happened, it can always and permanently be cleared by I also tried to find a way that solves the problem before it strikes, but was only half successful. After LDAP user creation, I run |
I'm experimenting the same problem, with the same ldap+oc installation except it was not an upgrade, but a fresh install. Tryied 9.0.2 update and didn't solve it. Also " I'm wondering what solution did @jakob42 apply when he said "I've copied that users data and it works now". Into which database table and what info did you exacly copy? or you just created the folder's structure of that new user...? Thanks! |
I was able to solve it this way: For all new ldap users (that never logged in), I manually created the structure (with a bash script reading all ldap new users and checking if their folder doesn't exist):
That's it! Note that this problem only happens if you share a file/folder with another user, and this user never logged in. (I also experienced this problem with already logged users which are not new when they change the shared folder/file name, but I was not able to reproduce the steps and got solved by itself) oc fix suggestion: when new user X loggs in, if another user Y shared folder to X, and the folder doesnt exist, create it automaticaly, if not, this error happens. |
That suggested fix would be great! Thomas Hohm m:con - mannheim:congress GmbH Phone +49 621 4106 175 Entdecken Sie WEITBLICKhttp://mcon-weitblick.de/weitblick-5/, das m:con Magazin für die Veranstaltungsbranche. Sitz Mannheim Amtsgericht Mannheim, HRB 5582 Abonnieren Sie unseren m:con Newsletter.http://www.mcon-mannheim.de/newsletter/ [cid:facebook_a65b9b6c-3d2b-42cb-a24e-f012dd2efd84.png]http://news.mcon-mannheim.de/gu/10/1CBNY8IC-1CBNY8I9-108QJ1O9-HU016U7.html [cid:twitter_8481ca08-65a4-4d46-97be-3ecd29067710.png] http://news.mcon-mannheim.de/gu/10/1CBNY8IC-1CBNY8I9-QHH8C5V-NSH1L0.html http://news.mcon-mannheim.de/gu/10/1CBNY8IC-1CBNY8I9-108QJ1O8-30U14E8.html [cid:xing_09ae54db-abe1-4b1b-b9a0-8ea668a4222b.png] http://news.mcon-mannheim.de/gu/10/1CBNY8IC-1CBNY8I9-128CIE1I-12EP7E7.html [cid:youtube_786e6d2e-db4f-4c55-934a-2497f5ba04b5.png] http://news.mcon-mannheim.de/gu/10/1CBNY8IC-1CBNY8I9-108QJ1O7-100116F.html This email was scanned by Bitdefender |
I have hit this bug in 9.0.0, and patched it to log the backtrace. Here it is:
|
Hmm, I still don't get why the login doesn't work. At login time there's code that would prepare the user's home folder and copy the skeleton files there. Maybe something else interefered and prevented that logic to run. As for the part about the cron job for a user who never logged in, that one is likely a bug. @owncloud/ldap @icewind1991 |
If by "something" you mean an app, at that point I've had only used packaged apps, no externals at all. |
@PVince81 , Does it create not only the skeleton files for user A, but also any other previously shared folder from user B (shared with that new user A that never logged in)? I think the problem is that. I had no problems when a user logged in and had no shared folder into him, and, another user was not able to enter and the only difference was that somebody shared a folder. Did testing with a 3rd user, and I was able to reproduce the problem; A shared folder is not automatically created or some problem related with new users and shared folders. |
@marcandreu received shared folders are not really created, but rather mounted. They only exist on the virtual OC filesystem that you see when browsing in the web UI. But as you say, maybe there's a bug in the code path that mounts those shared folders. @owncloud/sharing |
@PVince81 To help a bit to clear it out; i'm able to reproduce de error if the folder But I was able to reproduce the same error when I had no |
I can confirm, workaround (#24423 (comment)) from @marcandreu helps. If "share_folder" is configured in the config.php, it needs to be created too. Thanks! 00005595 |
I can confirm the problem with LDAP users who have never logged in before and who got access to a shared folder in ownCloud-9.0.2 on Apache-2.4.12, PHP-5.6.8 and Oracle Solaris 11.3. It doesn't matter whether the folder access is giving indirectly by an LDAP group membership or by sharing a folder with the specified user directly. Removing the 'share_folder' => '/Shared' relation in config.php also does not help. |
Do I understand it well that these users get access to the share through a group share ? |
Steps:
The folder "received_shares" is properly created at login time. This is with openLDAP and the v9.0.2 git version. Will retry with a tarball version since it comes with more apps, in case there is a side effect... |
We did the following steps using the released 9.0.2:
{"reqId":"wJOk0g6DIQ0NogTA0ovw","remoteAddr":"134.60.72.139","app":"PHP","message":"Call to a member function file_exists() on null at /srv/www/vhosts/netzwerk-offene-hochschulen.saps.uni-ulm.de/htdocs_ssl/owncloud/lib/private/files/filesystem.php#696","level":3,"time":"2016-06-16T14:27:13+00:00","method":"POST","url":"/owncloud/","user":"--"} After being stuck here, we tried an alternative way: Steps 1 and 2 are the same. The problem can be prevented when doing the following work-around: So the problem only occurs if a user has to receive a share while he/she logs in to ownCloud for his/her very first time. It is especially independent from the way of receiving the share - via a group membership or directly (by making a directory accessible on a by-user base). The problem has been a bit more complex at first, because in the beginning our users didn't see any LDAP groups at all in ownCloud- This was due to the fact that the attribute "useMemberOfToDetectMembership" has been active in the LDAP settings after the installation of ownCloud. As our OpenLDAP server does not support the MemberOf-functionality (due to the usage of posixAccount), I had to disable this function by setting it to "0". As some of users already logged in when this attribute was still "1", they didn't experience the problem. Only the users who were created (and did their first log in) after setting the "useMemberOfToDetectMembership" to "0" ran into the problem. Removing 'share_folder' => '/Shared' from config.php didn't help so far. |
@steffen-moser thanks for the details. So far I wasn't able to reproduce it but also my environement doesn't involve "useMemberOfToDetectMembership". I used the "memberUid" for group memberships. I'm not sure whether/how/why this would cause newly created user to not receive the shares. What if a user is in a group and doesn't receive any group shares ? I guess such new user can log in properly ? |
Here is my config:
@steffen-moser I guess you're also not using the "home_folder_naming_rule" attribute ? |
Tried again with a default 9.0.2 enterprise tarball with the same server and settings. I see that @thmcon had use_memberof_to_detect_membership also set to 1, so it's probably not related to the issue. But it is also likely that everyone here is talking about different issues with similar symptoms. So far it seems there are two cases:
|
Looking at @patrakov's stack trace here #24423 (comment) shows that the email address is being read from LDAP and that's the moment the "problem" occurs. I see that this attribute is also set for @thmcon. Will try with email address now. |
Nope, even with the "mail" attribute I don't get any errors. However so far I noticed that even if I have "share_folder" in config.php, that folder is never created and the existing share simply appear in the root of the newly logged in user. And then I tried sharing a NEW folder after changing config.php => 💣 Will try to gather more detailed steps now. |
Steps on v9.0.2:
Weird stuff: somehow it seems the attributes in the advanced tab were correct the first time but when I went back later then changed back to default. Had to re-set them to make group memberships work. |
In general, the stack trace from #24423 (comment) already shows a lot. What happens:
CC @rullzer @DeepDiver1975 for address book / avatar stuff Now either we need to have the FS ready earlier or try and skip triggering the user change event when it's the first time login. |
CC @icewind1991 I guess this whole thing might be missing an earlier |
Tried adding Ideally I think that the email's "user update" hook should be deferred to a later moment. Not sure if LDAP will sync the user's email again after the next TTL round. |
This is the place where Compact stack trace:
|
Here's a quick fix that makes login work again: #25150 This fix makes it use a properly initialized filesystem View object instead of relying of the non-initialized static one. We still need a better fix, likely one that doesn't trigger the whole "user update" event. |
Thanks for the feedback, glad to hear the workaround worked. |
The quickfix will be released as part of 9.0.3. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Steps to reproduce
Expected behaviour
The user should be able to login to the owncloud webpage and should get the "welcome message" and should be able to handle files.
On the webserver's file system there should be a new directory created with the directory name = his username.
Actual behaviour
The user enters his passowrd and tries to logon. He receives the webserver error 500.
The apache logfile shows the following entry:
PHP Fatal error: Call to a member function file_exists() on a non-object in /var/www/owncloud/lib/private/files/filesystem.php on line 693
On the file system of the webserver, OC-Data-directory, there has no new sub-directory for this user been created.
If I create a user in owncloud and logon with this user, everything works fine (user not coming from active directory / LDAP).
If I take a user which has been created from actie directory/LDAP in owncloud version 8.x, everything works fine (the user fodler in data directory has been created correctly under 8.x)
Server configuration
Operating system: ubuntu 14.04
Web server: apache 2.4.7
Database: mysql
PHP version: 5.5.9
ownCloud version: (see ownCloud admin page) 9.0.1.3
Updated from an older ownCloud or fresh install: updated from 8.x (took each single step, no version left out)
Where did you install ownCloud from: download tar file from owncloud.org
Signing status (ownCloud 9.0 and above):
no idea what I should enter here... please reply what I should add here... sorry
List of activated apps:
Enabled:
Disabled:
The content of config/config.php:
{
"system": {
"instanceid": "513af407e8f2d",
"passwordsalt": "_REMOVED SENSITIVE VALUE",
"datadirectory": "/mnt/sdb1/owncloud_data",
"dbtype": "mysql",
"version": "9.0.1.3",
"installed": true,
"memcache.local": "\OC\Memcache\APC",
"ldapIgnoreNamingRules": false,
"loglevel": 1,
"maintenance": false,
"theme": "",
"trusted_domains": [
"abc.domain.com",
"xyz.domain.com"
],
"share_folder": "/Shared",
"secret": "_REMOVED SENSITIVE VALUE",
"forcessl": true,
"forceSSLforSubdomains": true,
"mail_from_address": "it",
"mail_smtpmode": "smtp",
"mail_domain": "domain.com",
"mail_smtphost": "10.180.1.203",
"mail_smtpport": "25",
"dbname": "owncloud",
"dbhost": "10.180.1.48",
"dbuser": "_REMOVED SENSITIVE VALUE",
"dbpassword": "_REMOVED SENSITIVE VALUE"
}
}
Are you using external storage, if yes which one: external = local disk on same server, just the data directory outside the webserver directory. see config.
Are you using encryption: no
Are you using an external user-backend, if yes which one: ActiveDirectory
LDAP configuration (delete this part if not used)
+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Configuration | s02 |
+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+
| hasMemberOfFilterSupport | 1 |
| hasPagedResultSupport | |
| homeFolderNamingRule | |
| lastJpegPhotoLookup | 0 |
| ldapAgentName | CN=LDAP-Anmeldeuser,OU=Service-User,OU=Benutzer,OU=Organisation,DC=domain,DC=com |
| ldapAgentPassword | *** |
| ldapAttributesForGroupSearch | |
| ldapAttributesForUserSearch | |
| ldapBackupHost | |
| ldapBackupPort | |
| ldapBase | DC=domain,DC=com |
| ldapBaseGroups | DC=domain,DC=com |
| ldapBaseUsers | DC=domain,DC=com |
| ldapCacheTTL | 600 |
| ldapConfigurationActive | 1 |
| ldapDynamicGroupMemberURL | |
| ldapEmailAttribute | mail |
| ldapExperiencedAdmin | 0 |
| ldapExpertUUIDGroupAttr | |
| ldapExpertUUIDUserAttr | |
| ldapExpertUsernameAttr | |
| ldapGroupDisplayName | cn |
| ldapGroupFilter | (&(|(objectclass=group))) |
| ldapGroupFilterGroups | |
| ldapGroupFilterMode | 0 |
| ldapGroupFilterObjectclass | group |
| ldapGroupMemberAssocAttr | member |
| ldapHost | 10.180.1.201 |
| ldapIgnoreNamingRules | |
| ldapLoginFilter | (&(&(|(objectclass=organizationalPerson)(objectclass=person)(objectclass=user)))(|(samaccountname=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid)))) |
| ldapLoginFilterAttributes | |
| ldapLoginFilterEmail | 1 |
| ldapLoginFilterMode | 0 |
| ldapLoginFilterUsername | 1 |
| ldapNestedGroups | 0 |
| ldapOverrideMainServer | |
| ldapPagingSize | 500 |
| ldapPort | 389 |
| ldapQuotaAttribute | |
| ldapQuotaDefault | |
| ldapTLS | 0 |
| ldapUserDisplayName | displayname |
| ldapUserDisplayName2 | |
| ldapUserFilter | (&(|(objectclass=organizationalPerson)(objectclass=person)(objectclass=user))(|(|(memberof=CN=Domänen-Benutzer,CN=Users,DC=domain,DC=com)(primaryGroupID=513)))) |
| ldapUserFilterGroups | Domänen-Benutzer |
| ldapUserFilterMode | 0 |
| ldapUserFilterObjectclass | organizationalPerson;person;user |
| ldapUuidGroupAttribute | auto |
| ldapUuidUserAttribute | auto |
| turnOffCertCheck | 0 |
| useMemberOfToDetectMembership | 1 |
+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Configuration | s03 |
+-------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| hasMemberOfFilterSupport | 1 |
| hasPagedResultSupport | |
| homeFolderNamingRule | |
| lastJpegPhotoLookup | 0 |
| ldapAgentName | CN=LDAP-Anmeldeuser,OU=Service-User,OU=Benutzer,OU=Organisation,DC=domain,DC=com|
| ldapAgentPassword | *** |
| ldapAttributesForGroupSearch | |
| ldapAttributesForUserSearch | |
| ldapBackupHost | |
| ldapBackupPort | |
| ldapBase | DC=domain,DC=com|
| ldapBaseGroups | DC=domain,DC=com |
| ldapBaseUsers | DC=domain,DC=com |
| ldapCacheTTL | 600 |
| ldapConfigurationActive | 1 |
| ldapDynamicGroupMemberURL | |
| ldapEmailAttribute | |
| ldapExperiencedAdmin | 0 |
| ldapExpertUUIDGroupAttr | |
| ldapExpertUUIDUserAttr | |
| ldapExpertUsernameAttr | |
| ldapGroupDisplayName | cn |
| ldapGroupFilter | |
| ldapGroupFilterGroups | |
| ldapGroupFilterMode | 0 |
| ldapGroupFilterObjectclass | |
| ldapGroupMemberAssocAttr | uniqueMember |
| ldapHost | 10.180.1.202 |
| ldapIgnoreNamingRules | |
| ldapLoginFilter | (&(&(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person)(objectclass=user)))(|(samaccountname=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid)))) |
| ldapLoginFilterAttributes | |
| ldapLoginFilterEmail | 1 |
| ldapLoginFilterMode | 0 |
| ldapLoginFilterUsername | 1 |
| ldapNestedGroups | 0 |
| ldapOverrideMainServer | |
| ldapPagingSize | 500 |
| ldapPort | 389 |
| ldapQuotaAttribute | |
| ldapQuotaDefault | |
| ldapTLS | 0 |
| ldapUserDisplayName | displayname |
| ldapUserDisplayName2 | |
| ldapUserFilter | (&(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person)(objectclass=user))) |
| ldapUserFilterGroups | |
| ldapUserFilterMode | 0 |
| ldapUserFilterObjectclass | organizationalPerson;person;user |
| ldapUuidGroupAttribute | auto |
| ldapUuidUserAttribute | auto |
| turnOffCertCheck | 0 |
| useMemberOfToDetectMembership | 1 |
+-------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Client configuration
Browser: Firefox, Chrome, Internet Explorer
Operating system: Windows 8.1, Windows 7
Logs
Web server error log
[Tue May 03 16:05:40.213672 2016] [:error] [pid 5464] [client 10.180.18.26:44403] PHP Fatal error: Call to a member function file_exists() on a non-object in /var/www/owncloud/lib/private/files/filesystem.php on line 693
[Tue May 03 16:05:47.039942 2016] [:error] [pid 5454] [client 10.180.18.26:44407] PHP Fatal error: Call to a member function file_exists() on a non-object in /var/www/owncloud/lib/private/files/filesystem.php on line 693
[Tue May 03 16:05:53.116388 2016] [:error] [pid 5452] [client 10.180.18.26:44488] PHP Fatal error: Call to a member function file_exists() on a non-object in /var/www/owncloud/lib/private/files/filesystem.php on line 693
[Tue May 03 16:19:55.750866 2016] [:error] [pid 5455] [client 10.180.5.54:45340] PHP Fatal error: Call to a member function file_exists() on a non-object in /var/www/owncloud/lib/private/files/filesystem.php on line 693
Owncloud-Log
{"reqId":"rGfG5VjBMEWwH91sZmYQ","remoteAddr":"10.180.5.54","app":"user_ldap","message":"Looking for cookie L/O 500/0","level":1,"time":"2016-05-03T14:19:54+00:00","method":"GET","url":"/cron.php","user":"--"}
{"reqId":"rGfG5VjBMEWwH91sZmYQ","remoteAddr":"10.180.5.54","app":"user_ldap","message":"No paged search for us, Cpt., Limit 500 Offset 500","level":1,"time":"2016-05-03T14:19:54+00:00","method":"GET","url":"/cron.php","user":"--"}
{"reqId":"rGfG5VjBMEWwH91sZmYQ","remoteAddr":"10.180.5.54","app":"user_ldap","message":"Paged search was not available","level":1,"time":"2016-05-03T14:19:54+00:00","method":"GET","url":"/cron.php","user":"--"}
{"reqId":"rGfG5VjBMEWwH91sZmYQ","remoteAddr":"10.180.5.54","app":"user_ldap","message":"Looking for cookie L/O 500/0","level":1,"time":"2016-05-03T14:19:55+00:00","method":"GET","url":"/cron.php","user":"--"}
{"reqId":"rGfG5VjBMEWwH91sZmYQ","remoteAddr":"10.180.5.54","app":"user_ldap","message":"No paged search for us, Cpt., Limit 500 Offset 500","level":1,"time":"2016-05-03T14:19:55+00:00","method":"GET","url":"/cron.php","user":"--"}
{"reqId":"rGfG5VjBMEWwH91sZmYQ","remoteAddr":"10.180.5.54","app":"user_ldap","message":"Paged search was not available","level":1,"time":"2016-05-03T14:19:55+00:00","method":"GET","url":"/cron.php","user":"--"}
{"reqId":"rGfG5VjBMEWwH91sZmYQ","remoteAddr":"10.180.5.54","app":"PHP","message":"Call to a member function file_exists() on a non-object at /var/www/owncloud/lib/private/files/filesystem.php#693","level":3,"time":"2016-05-03T14:19:55+00:00","method":"GET","url":"/cron.php","user":"--"}
The text was updated successfully, but these errors were encountered: