[Bug]: Profile Picture from LDAP gone after upgrade to 25

[mstrandbo]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

My server is setup with an LDAP backend (FreeIPA), which has been working great since v22 or so.
I have some users with a profile picture stored in the LDAP backend, using the attribute 'jpegphoto'. This has worked fine for all clients (web, desktop, android).
However, after I upgraded the server to Hub 3 / 25.0.0 and 25.0.1 the pictures are gone, and I can just see the initals.

When going to my profile, it seems to acknowledge that I have a profile picture from LDAP:

If I remove it from the backend, I can set a picture here manually again.
Tried with incognito mode and new devices/browsers incase it was some caching issues, which it wasn't.

Has the format changed or something like that?

Steps to reproduce

Expected behavior

Chosen profile picture in LDAP backend should be displayed.

Installation method

Community VM appliance

Operating system

Debian/Ubuntu

PHP engine version

PHP 7.4

Web server

Apache (supported)

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

Updated to a major version (ex. 22.2.3 to 23.0.1)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "172.17.30.121",
            "cloud.redacted.no",
            "cloud.home.redacted.org",
            "web.home.redacted.org",
            "172.17.30.130"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "25.0.1.1",
        "overwrite.cli.url": "https:\/\/cloud.redacted.no\/",
        "overwritehost": "cloud.redacted.no",
        "overwriteprotocol": "https",
        "allow_local_remote_servers": "true",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "upgrade.disable-web": "true",
        "log_type": "file",
        "logfile": "\/var\/log\/nextcloud\/nextcloud.log",
        "loglevel": "2",
        "log.condition": {
            "apps": [
                "admin_audit"
            ]
        },
        "mail_smtpmode": "smtp",
        "remember_login_cookie_lifetime": 1296000,
        "log_rotate_size": "10485760",
        "trashbin_retention_obligation": "auto, 180",
        "versions_retention_obligation": "auto, 365",
        "simpleSignUpLink.shown": "false",
        "filelocking.enabled": true,
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0.5,
            "dbindex": 0,
            "password": "***REMOVED SENSITIVE VALUE***"
        },
        "logtimezone": "Europe\/Oslo",
        "ldapIgnoreNamingRules": false,
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
        "maintenance": false,
        "default_locale": "nb_NO",
        "mail_sendmailmode": "smtp",
        "mail_smtpauthtype": "PLAIN",
        "mail_smtpauth": 1,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "has_rebuilt_cache": true,
        "default_phone_region": "no",
        "htaccess.RewriteBase": "\/",
        "session_lifefime": 86400,
        "memcache.local": "\\OC\\Memcache\\Redis",
        "mail_smtpsecure": "tls"
    }
}

List of activated Apps

Enabled:
  - activity: 2.17.0
  - calendar: 4.1.0
  - circles: 25.0.0
  - cloud_federation_api: 1.8.0
  - comments: 1.15.0
  - contactsinteraction: 1.6.0
  - dashboard: 7.5.0
  - dav: 1.24.0
  - federatedfilesharing: 1.15.0
  - federation: 1.15.0
  - files: 1.20.1
  - files_external: 1.17.0
  - files_pdfviewer: 2.6.0
  - files_rightclick: 1.4.0
  - files_sharing: 1.17.0
  - files_trashbin: 1.15.0
  - files_versions: 1.18.0
  - firstrunwizard: 2.14.0
  - logreader: 2.10.0
  - lookup_server_connector: 1.13.0
  - nextcloud_announcements: 1.14.0
  - notes: 4.6.0
  - notifications: 2.13.1
  - oauth2: 1.13.0
  - password_policy: 1.15.0
  - photos: 2.0.0
  - privacy: 1.9.0
  - provisioning_api: 1.15.0
  - recommendations: 1.4.0
  - related_resources: 1.0.3
  - richdocuments: 7.0.1
  - serverinfo: 1.15.0
  - settings: 1.7.0
  - sharebymail: 1.15.0
  - sharerenamer: 3.1.0
  - spreed: 15.0.1
  - support: 1.8.0
  - survey_client: 1.13.0
  - systemtags: 1.15.0
  - text: 3.6.0
  - theming: 2.0.1
  - twofactor_backupcodes: 1.14.0
  - updatenotification: 1.15.0
  - user_ldap: 1.15.0
  - user_status: 1.5.0
  - viewer: 1.9.0
  - weather_status: 1.5.0
  - workflowengine: 2.7.0
Disabled:
  - accessibility
  - admin_audit
  - bruteforcesettings
  - encryption
  - files_videoplayer
  - richdocumentscode: 22.5.802
  - suspicious_login
  - twofactor_totp

Nextcloud Signing status

No response

Nextcloud Logs

{"reqId":"6yPdD9LOXh3tVdzhNolF","level":0,"time":"2022-11-22T09:29:14+01:00","remoteAddr":"172.20.0.3","user":"morten","app":"user_ldap","method":"GET","url":"/ocs/v2.php/apps/notifications/api/v2/notifications?format=json","message":"initializing paged search for filter (|(uid=morten)(mail=morten)), base cn=users,cn=accounts,dc=home,dc=redacted,dc=org, attr [\"entryuuid\",\"nsuniqueid\",\"objectguid\",\"guid\",\"ipauniqueid\",\"dn\",\"uid\",\"samaccountname\",\"memberof\",\"mail\",\"displayname\",\"jpegphoto\",\"thumbnailphoto\"], limit 500, offset 0","userAgent":"Mozilla/5.0 (Windows) mirall/3.3.0stable-Win64 (build 20210729) (Nextcloud, windows-10.0.17763 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.1.1","data":{"app":"user_ldap"}}

Additional info

No response

[PVince81]

is this connected to known theming issues @skjnldsv ?

or a regression with LDAP ? @come-nc @blizzz

[mstrandbo]

Pardon, I forgot to mention in the original post that this also have affected the clients (Android, Windows at least). Just the Initials there too.

[hpvb]

I have the same issue as well, mostly. On my nextcloud instance that had LDAP synchronized profile pictures before the upgrade to 25 the old ones remain but updates are no longer synchronized.

I have since also installed a new server with 25 for a different project and on this new server jpegPhoto isn't synchronized at all and lastJpegPhotoLookup stays at 0 according to ./occ ldap:show-config

[hpvb]

I do not know if this is relevant but ./occ background-job:list does not show any LDAP jobs. From a cursory look at the code I would expect some mention of the job defined in apps/user_ldap/lib/Jobs/Sync.php to be listed.

If this is the case it appears that perhaps 48d9c4d is at fault here? Is it possible that that caused this problem @CarlSchwan ?

[come-nc]

$ occ background-job:list -c 'OCA\User_LDAP\Jobs\Sync'
+----+-------------------------+---------------------------+----------+
| id | class                   | last_run                  | argument |
+----+-------------------------+---------------------------+----------+
| 18 | OCA\User_LDAP\Jobs\Sync | 2023-01-05T07:54:07+00:00 | null     |
+----+-------------------------+---------------------------+----------+

I do see it on my instance which was updated to 25 yesterday.

[come-nc]

On a test instance with latest master, jpegPhoto is correctly sync on first login of an LDAP user.
Sync job is listed in the job list as well. I’m waiting to see if it sync avatars on non-logged in users.

@hpvb @mstrandbo Can you both try occ background-job:list -c 'OCA\User_LDAP\Jobs\Sync' to see if the job is planned?

[mstrandbo]

Yes, it does give me this:

$ sudo -u www-data ./occ  background-job:list -c 'OCA\User_LDAP\Jobs\Sync'
+-----+-------------------------+---------------------------+----------+
| id  | class                   | last_run                  | argument |
+-----+-------------------------+---------------------------+----------+
| 145 | OCA\User_LDAP\Jobs\Sync | 2023-01-05T09:20:03+00:00 | null     |
+-----+-------------------------+---------------------------+----------+

As an aside now, when I log in and look at my profile-button in the top right, it'll just say my initials.
However, when I click the Contacts-button beside it, and scroll to myself, it'll show an broken image.

I'm updated to 25.0.2 since creating this issue, by the way.

[come-nc]

@mstrandbo You do not have any useful error in your logfile related to this?
If you open your browser console (usually F12), do you see more details on the error getting the image (is it 404, 500, 200 with invalid image data?). You may have to reload the page after opening the console.

[mstrandbo]

@come-nc I do struggle to find any relevant information in the logfile. It's a bit chaotic to be honest :) What loglevel should I use?

The Console tells me:

Failed to load resource: the server responded with a status of 404 ()

If I right-click and open the picture in a new tab, it just shows me two brackets [ ]

All other instances where it should be showing is still just the initials as in the original post.

[come-nc]

@mstrandbo This is specific to the avatar, the email field is correctly sync from LDAP?

[mstrandbo]

@come-nc Yes, email fields are correct.

Some new info. I tried adding jpegPhoto to a new user now, and his photo showed up right away. The problem appears to be with users with existing photos. I'll remove the photo I've used on my profile now, together with the entire attribute. Then let it sit a day or so before adding it back.
My profile does let me add a new profile picture in Nextcloud now, so it seems to have picked up that the attribute is gone..

[hpvb]

I see the following:

$ ./occ background-job:list -c 'OCA\User_LDAP\Jobs\Sync'
+----+-------------------------+---------------------------+----------+
| id | class                   | last_run                  | argument |
+----+-------------------------+---------------------------+----------+
| 37 | OCA\User_LDAP\Jobs\Sync | 2023-01-05T06:50:04+00:00 | null     |
+----+-------------------------+---------------------------+----------+

Still no jpegPhoto though:

I see no output in nextcloud.log at all, I could try increasing the loglevel perhaps, what would be a good setting?

EDIT:

All other LDAP fields appear to work properly, group memberhips, display name, email address, etc.

Relevant LDAP data for this user:

[mstrandbo]

Tried re-adding my profile photo to my freeipa today, but no dice. Still the same behaviour.

So there's some information to take with us maybe? A user who have never had a photo, then got a photo set by ldap, will have it show up.
But users who had a photo already, lost them and it does not get re-added. Would there be any way to remove all profile photos and force a resync of some sort?

[Daryes]

I'm getting the same problem on some users, too, with nextcloud 25.0.2 (php 8.0.21) and an active directory domain.
The properties are the same than for ldap (jpegphoto, thumbnailphoto, ...). Character case aside.
The users have no problem to log in, obviously

There wasn't any problem with nextcloud 22, and the problematic users have their avatars correctly visible in other tools and apps.
It seems at random, and nothing from the log gives any hint (or I'm too blind to see it).

What I've gathered:

• there doesn't seems to be any reference in the db, aside the oc_filecache table
• the avatars are located under the nextcloud data directory, at : app_<random id>/avatar/<user email or uid/
• an empty generated file will be created when the avatar are generated using the user initials
• generated avatars are in png format
• retrieved avatars from ldap / ad are in jpg format (some files exist since more than 2 years)
• removing a jpeg avatar from a user will end in a png generated avatar after some minutes (might need to wait for the cron execution). This won't be corrected to the jpeg avatar, even hours after.

Also, the occ commands preview:repair and preview:reset-rendered-texts does not have any effect on this.

To me, it seems nextcloud is using the cached avatar images, and if a user has one of the avatar files missing (there are multiple sizes), or any unknown reason, will remove them and generate new avatar files in png format for the given user.
This without (trying to ? ) retrieving those available on ldap/ad

[einhander]

The same issue on my server. Regeneration of avatar does no effect.

[arturodc37]

The same problem too.

[einhander]

The same problem too.

You can remove user pic from ldap, and add it back to solve the issue. Upgrade to 25.0.5 doesn't seems solve it.

[Keyinator]

I've been trying to get ldap jpegphoto to work for hours.
This is still not fixed? :(

[nsilent22]

I had a similar issue. After the upgrade some of the avatars were gone. The routine checking the avatar image from LDAP does a checksum comparison and returns when checksum matches the last one saved. That's why changing user pic in LDAP can trigger regeneration.
What I did was just clearing this attribute:
sudo -u www-data ./occ user:setting USER_ID_HERE user_ldap lastAvatarChecksum ''
Now, when user USER_ID_HERE logs in, his avatar will be regenerated.

[maxemann96]

Both workarounds mentioned above are not working for me. Nextcloud: 26.0.2.

[blizzz]

Might want to check whether #39128 helps here. Didn't test it myself, quick and rough PR based on @nsilent22's observation 🍀

[herrmannsdorfer]

#35319 (comment) works fine here on NC 25.0.8. Thanks for the workaround @nsilent22!

Hopefully #39128 will be backported to NC 25.

[jmerino-iib]

As root, having username without spaces or colons, this has worked for me in bash:

for u in `su -s /bin/sh -c  "./occ user:list" www-data | sed 's/^  - \([^:]*\):.*/\1/'`; do
  su -s /bin/sh -c  "./occ user:setting $u user_ldap lastAvatarChecksum ''" www-data
done