Album cover thumbnail replaced by padlock icon for the album owner when a password is set

[MNS735]

Lychee version

Lychee 7.8.3

Did you check the latest Lychee version?

Yes, I did

Which PHP version are you using?

PHP 8.5

Detailed description of the problem

When an album is password-protected, the album overview shows img/password.svg (padlock icon) instead of the album cover thumbnail — also for the album owner while logged in as admin.

Hiding the cover from anonymous visitors makes sense. But for the owner in an authenticated session there seems to be no reason to hide it, and it makes managing a gallery visually difficult: with several protected albums the overview is just a row of padlocks, so albums can no longer be recognised at a glance.

Setting a cover image explicitly does not change the behaviour.

Evidence from my instance

Single user install, users.id = 1, all albums have base_albums.owner_id = 1. Logged in as that user, hard-reloaded the page.

Album	albums.cover_id	access_permissions.password	Overview shows
Engadin	set	NULL	cover thumbnail
ÄLPLI 2026	set	set	padlock
Theaterspektakel 26	set	set	padlock

So the padlock correlates with the password, not with a missing cover.

Rendered markup for a protected album:

<img alt="Foto-Miniaturansicht" class="w-full h-full m-0 p-0 border-0 object-cover invert brightness-25 dark:invert-0 dark:brightness-100"
     src="https://<host>/img/password.svg" srcset="" data-overlay="false" draggable="false" loading="lazy">

The nginx access log shows no request to /uploads/thumb/... for these albums, so the thumbnail URL is never emitted by the API rather than being blocked client-side.

Steps to reproduce the issue

1. Log in as admin (owner of all albums).
2. Create album A, set a cover image, make it public, no password.
3. Create album B, set a cover image, make it public, set a password.
4. Open the album overview while still logged in.
5. Album A shows its cover; album B shows the padlock icon.

Diagnostics [REQUIRED]

info
Hash: d6c3d28fff8f4d73—96826e69c13d2d15
4059 files and 15632 vendor files
info
Full directory permission check is disabled
error
APP_URL (https://galler*************rew.com) does not match the current url (http://galler*************rew.com).
This will break WebAuthn authentication.
error
APP_URL (https://galler*************rew.com) does not match the current url (http://galler*************rew.com).
This will prevent images from being properly displayed.
warning
Default timezone not properly set; you might experience strange results when importing photos without explicit EXIF timezone
info
Have you considered supporting Lychee? :)

Browser & System [REQUIRED]

Info

Lychee Version (release): 7.8.3
DB Version: 7.8.3
Docker: lycheeorg
composer install: --no-dev
APP_ENV: production
APP_DEBUG: false
APP_URL: set
APP_DIR: default
LOG_VIEWER_ENABLED: false
System: Linux
PHP Version: 8.5.9
PHP User agent: Lychee/6 (https://lycheeorg.dev/)
int size 64 bits 8
Timezone: UTC
Max uploaded file size: 100M
Max post size: 100M
Chunk size: 25.60 MB
Max execution time: 3600
MySQL Version: 10.11.19-MariaDB-ubu2204
exec() Available: yes
Imagick Available: 1
Imagick Enabled: yes
Imagick Version: 1809
GD Version: 2.3.3
Number of foreign key: 55 found.

Please confirm (incomplete submissions will not be addressed)

• I have provided easy and step-by-step instructions to reproduce the bug.
• I understand my bug report will be removed if I haven't met the criteria above.
• I understand that if I am requested to provide more information, I must do so within 14 days or the bug report will be closed.

[gyanu2507]

That looks like a real bug, not a missing cover.

The overview is emitting src="/img/password.svg" for passworded albums even when you are the owner (users.id = 1, owner_id = 1). Nginx never seeing /uploads/thumb/... means the API chose the padlock URL. Setting cover_id cannot win if the serializer short-circuits on “album has a password.”

Hiding the cover from anonymous visitors is correct. For an authenticated owner/admin session it should still return the thumbnail. Workaround until a patch: do not password albums you need to recognize in the grid, or use a parent album without a password and protect the children another way (hidden + share link). That is a poor substitute.

A fix is: in the album resource / overview DTO, use the padlock only when the current user cannot unlock the album. Owner and users with the unlock already in session should get cover_id like an unprotected album. Your table (password set ↔ padlock, password NULL ↔ cover) is enough to attach to an issue.

[ildyria]

That is indeed a bug.