Users with LDAP photos unable to see SMB external storage on OwnCloud Android app #21555

Closed
dbenz04 opened this Issue Jan 8, 2016 · 22 comments

Projects

None yet
@dbenz04
dbenz04 commented Jan 8, 2016

Original issue here: 1284

Most of our OwnCloud LDAP users have a photo associated with their AD account, usually in both jpegPhoto and thumbnailPhoto. Every OwnCloud user with an LDAP-provided avatar photo cannot see their SMB external storage in the Android client.

To test this theory, I added a photo in AD for one of the users whose account was previously working on Android. After logging in through the web interface and seeing the new profile avatar, I tried the Android client again. This user can no longer see their external storage.

Using a separate Android WebDAV client kind of works - Initially no external storage is shown for these users, but if you use the refresh button within the app the storage appears. Using the "refresh account" option in the Owncloud Android app does not show external storage. These users can see their external storage on the iOS Android app.

Since disabling syncing of LDAP photos/avatars woudl presumably fix this issue, does anyone know how this could be accomplished? I've looked around several config files and database tables, but don't see an obvious way to disable this behavior.

OwnCloud version: 8.2.2
OS: Ubuntu 14.04
Web server: Apache 2.4
Database server: MySQL
Memcache: Redis
Using External storage via SMB using OwnCloud session credentials
No encryption used
Android client is latest from the Play Store, also tried the Beta from 20160103 with same results.

@karlitschek
Member

This is super weird. @rullzer @PVince81 any idea?

@dbenz04
dbenz04 commented Jan 8, 2016

Thanks for looking into this. I also verified that adding the show avatar photo=false in the config.php does not solve the problem since OwnCloud is still syncing the photos, it is just not showing them.

I also tried removing a user's photo from AD - that made the Android OwnCloud client work for that user.

@rullzer
Contributor
rullzer commented Jan 8, 2016

This is very weird indeed.

@blizzz as ldap expert... can you reproduce this behaviour?

@rullzer
Contributor
rullzer commented Jan 8, 2016

@dbenz04 does your ownCloud log tell you anything?

@dbenz04
dbenz04 commented Jan 8, 2016

Nope. I looked through the owncloud log and the apache log.

@blizzz
Contributor
blizzz commented Jan 8, 2016

Woah… I don't have an SMB at hand so I was trying to reproduce it as local. Already the web interface tells me (as LDAP user) that there is an issue with that mount and it cannot be access, 403 would be retrieved (although all the ajax results are good and don't differ as if requested with a local user). If I enter the folder by manipulating the URL, I see and can interact with the config. Already everything even without avatar, on current master.

On stable8.2 this works as it should. Even with Avatar fetched from LDAP/AD. (Using version 1.9 of the Android app). So, cannot confirm, but that was also just a local external storage.

Update: I did not use Redis either

@PVince81 PVince81 added this to the 9.0-current milestone Jan 11, 2016
@martingasserbern

The same here. I can confirm this bug.
LDAP Config and users with a avatar Pic can not see the smb_oc shares in Android APP. IOS is OK.
After removing the picture in AD, everything is ok.
Owncloud 8.2.2., Centos 7, MS AD

@blizzz
Contributor
blizzz commented Jan 29, 2016

Do you actually experience the same with local users?

@dbenz04
dbenz04 commented Jan 29, 2016

Local users cannot map our smb drives using session credentials, but adding an avatar to a local user doesn't cause any issues connecting to smb drives using a specified username and password on Android.

@blizzz blizzz added the sev2-high label Feb 12, 2016
@PVince81
Collaborator

Can anyone reproduce this locally ? @rullzer @blizzz

@blizzz
Contributor
blizzz commented Feb 23, 2016

LDAP Config and users with a avatar Pic can not see the smb_oc shares in Android APP. IOS is OK.

If iOS is okay, and the web interface, too, it rather looks like that the issue is to be found within the Android code.

I need to prepare a proper test setup first. My initial attempts to reproduce it did not succeed, but found other issues with files_external. I should further look into it, but have a couple of issue to look into for 9.0 lying around.

@dbenz04
dbenz04 commented Feb 23, 2016

If it helps with the troubleshooting, a simple WebDAV client on Android exhibits similar behavior. For a user with an LDAP pic, it initially does not show their external storage. If you manually refresh it, the external storage will show. For some reason, "refresh account" in the android owncloud client does not display the folders.

For a user without an LDAP pic, their external storage shows immediately in an Android WebDAV client.

@cmonteroluque
Contributor

@jesmrec @rperezb can you test with 8.2.2?

@rperezb
Member
rperezb commented Feb 25, 2016

@cmonteroluque I'm afraid I have just reproduced this issue.

@dbenz04 has said, it's related to the fact of having an avatar on the ldap server. While this is working on web ui and iOs, it's not on Android, so...I need the help of my android colleages @owncloud/android-developers

Probably, better to move this to the Android repo

@rperezb
Member
rperezb commented Feb 25, 2016

@blizzz

does it make you ring any bell the logs:

Error   PHP filesize(): stat failed for /opt/owncloud/data/abagail_toy/avatar.jpg at /opt/owncloud/lib/private/files/storage/local.php#139  2016-02-25T10:08:46+00:00
Error   PHP filemtime(): stat failed for /opt/owncloud/data/abagail_toy/avatar.jpg at /opt/owncloud/lib/private/files/storage/local.php#156
@blizzz
Contributor
blizzz commented Feb 25, 2016

@rperezb is abagail_toy the user folder you expect it to be?

@rperezb
Member
rperezb commented Feb 25, 2016

@blizzz not, abagail_toy is the user who has enable the avatar, the folder is called "external"

BTW, I have a test environment..if you want to check..ping me on IRC

@blizzz
Contributor
blizzz commented Feb 25, 2016

not, abagail_toy is the user who has enable the avatar, the folder is called "external"

@rperezb no, the warning is about that stat failed on the avatar file, and this lies within the user folder (/opt/owncloud/data/abagail_toy/avatar.jpg).

BTW, I have a test environment..if you want to check..ping me on IRC

will do!

@blizzz
Contributor
blizzz commented Feb 25, 2016

I am not able to reproduce it here either. I have only 1.9.0 on a Jolla Sailfish device. With no caching enabled it's also slow when the app checks all the files and subfolders even if only being on the top level of the file hierarchy.

< update> auth method in files_extern was switched, now i can reproduce < /update>

@rperezb was able to reproduce it with 1.9.1.

Also I could not force the stat errors to happen again, and they only appeared once in the log in general.

@rperezb
Member
rperezb commented Feb 25, 2016

@blizzz you have just reproduce too, don't you? just for tracking purposes

@blizzz
Contributor
blizzz commented Feb 25, 2016

I can also reproduce now using cadaver.

My theory was that for some reason the avatar is accessed first, before filesystem apps are being loaded. That's not the case.

However, in cadaver I tried to cd into the not visible folder. I got 500, saying that credentials were not safed.

My theory is following: if an avatar is present, it will be read before the credentials are being saved while at the same time initializing the file system.

The credentials are saved into the session after the post_login hook was thrown.

This happens for LDAP users, because upon login all relevant details are being fetched from LDAP, including the avatar. This requires that the avatar interfaces are being used, which instantiate the file system before the credentials are saved in the session.

A solution would be to act just the same way, connect to the post_login hook and set the avatar afterwards. It's a bit problematic, because we have no guaranteed order of processing the hook. It should be OK because we'd register late, still it is hackish.

The alternative is too totally move out LDAP's avatar refresh from normal operaitons and into a background job.

Also, this bugs only appears if an authentication is done with every request. If cookies are used, like in the web interface, this effect does not occur.

@davivel
Member
davivel commented Feb 25, 2016

Also, this bugs only appears if an authentication is done with every request. If cookies are used, like in the web interface, this effect does not occur.

That explains why the error only appeared with Android client, and not with iOS nor desktop. Android client authenticates in every request.

@blizzz blizzz assigned blizzz and unassigned jesmrec Feb 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment