LycheeOrg
Migrating 5.0.2 to 5.0.3 results in "Branch is not master"
Detailed description of the problem
When using the docker image and mariadb as a database, and upgrading to the version 5.0.3, the migration fails with the error Branch is not master. I was upgrading from version 5.0.2. Downgrading to the old version works and the lychee page displays correctly.
Looking at the attached logs, it seems like lychee is trying to access a sqlite DB to perform the migration, even if it was configured to access a mysql/mariadb database.
Steps to reproduce the issue
I am using the docker image of lychee. I have set up a minimal working example of the issue here: https://github.com/trailfog/lychee-migration-issue
- Run
docker compose up -d - Head over to http://localhost:8080 and set up the instance with an admin account
- Change the docker image of
lycheetolycheeorg/lychee:v5.0.3 - Run
docker compose up -d - Reload the page http://localhost:8080 and be greeted with a login (not the popover login), no site functionality available
- After the login, you can see the Migration result of
Branch is not master
If a new instance of lychee is set up using version 5.0.3, the migration issue does not show up.
Output of the diagnostics
-------------------------------------
_ _
| | _ _ ___| |__ ___ ___
| | | | | |/ __| _ \ / _ \/ _ \
| |__| |_| | (__| | | | __/ __/
|_____\__, |\___|_| |_|\___|\___|
|___/
-------------------------------------
Lychee Version: 5.0.3 (release)
Lychee Commit: b8ace78
https://github.com/LycheeOrg/Lychee/commit/b8ace78cb4f34d4da6a80c2ee43008948a88e75c
-------------------------------------
**** Delaying startup (5 seconds)... ****
**** Make sure the /conf /uploads /sym /logs folders exist ****
**** Create the symbolic link for the /uploads folder ****
**** Create the symbolic link for the /sym folder ****
**** Create the symbolic link for the /logs folder ****
**** Create the symbolic link for the database ****
**** Copy the .env to /conf ****
**** Inject .env values ****
sed: cannot rename /conf/sedzNSKsq: Device or resource busy
**** Generate the key (to make sure that cookies cannot be decrypted etc) ****
APPLICATION IN PRODUCTION.
WARN Command cancelled.
**** Migrate the database ****
In Connection.php line 822:
SQLSTATE[HY000] [1044] Access denied for user 'lychee'@'%' to database '/va
r/www/html/Lychee/database/database.sqlite' (Connection: mysql, SQL: select
table_name as `name`, (data_length + index_length) as `size`, table_commen
t as `comment`, engine as `engine`, table_collation as `collation` from inf
ormation_schema.tables where table_schema = '/var/www/html/Lychee/database/
database.sqlite' and table_type = 'BASE TABLE' order by table_name)
In Connector.php line 65:
SQLSTATE[HY000] [1044] Access denied for user 'lychee'@'%' to database '/va
r/www/html/Lychee/database/database.sqlite'
**** Make sure user.css exists and symlink it ****
**** Make sure custom.js exists and symlink it ****
**** Create user and use PUID/PGID ****
User UID : 1000
User GID : 100
**** Make sure Laravel's log exists ****
**** Set Permissions ****
**** Start cron daemon ****
Starting periodic command scheduler: cron.
**** Setup complete, starting the server. ****
Diagnostics
-----------
Warning: Dropbox import not working. dropbox_key is empty.
Warning: You may experience problems when uploading a photo of large size. Take a look in the FAQ for details.
Warning: You may experience problems when uploading a photo of large size. Take a look in the FAQ for details.
Error: Database is behind file version. Please apply the migrations.
Info: Latest version of PHP is 8.3
Warning: git (software) is not available.
System Information
------------------
Lychee Version (git): ?? (b8ace78) -- Could not compare.
DB Version: 5.0.2
composer install: --no-dev
APP_ENV: production
APP_DEBUG: false
APP_URL: set
APP_DIR: default
LOG_VIEWER_ENABLED: true
LIVEWIRE_ENABLED: false
System: Linux
PHP Version: 8.2.7
PHP User agent: Lychee/4 (https://lycheeorg.github.io/)
Timezone: Europe/Zurich
Max uploaded file size: 2M
Max post size: 8M
Livewire chunk size: 0.00 B
Max execution time: 0
MySQL Version: 10.11.6-MariaDB-1:10.11.6+maria~ubu2204
exec() Available: yes
Imagick Available: 1
Imagick Enabled: 1
Imagick Version: 1691
GD Version: 2.3.3
Number of foreign key: 11 found.
Config Information
------------------
version: 050002
check_for_updates: 0
sorting_photos_col: taken_at
sorting_photos_order: ASC
sorting_albums_col: title
sorting_albums_order: ASC
imagick: 1
skip_duplicates: 0
small_max_width: 0
small_max_height: 360
medium_max_width: 1920
medium_max_height: 1080
lang: en
image_overlay_type: none
default_license: CC-BY-4.0
compression_quality: 90
grants_full_photo_access: 1
delete_imported: 0
mod_frame_enabled: 1
mod_frame_refresh: 30
thumb_2x: 0
small_2x: 0
medium_2x: 0
landing_page_enable: 0
site_owner: ...
landing_title: ...
landing_subtitle: ...
sm_facebook_url:
sm_flickr_url:
sm_twitter_url:
sm_instagram_url:
sm_youtube_url:
landing_background: dist/cat.webp
site_title: ...
footer_show_copyright: 1
site_copyright_begin: 2019
site_copyright_end: 2023
footer_additional_text:
footer_show_social_media: 0
search_public: 1
SL_enable: 0
SL_for_admin: 0
recent_age: 1
grants_download: 0
photos_wraparound: 1
map_display: 1
zip64: 1
map_display_public: 1
map_provider: OpenStreetMap.org
force_32bit_ids: 0
map_include_subalbums: 1
update_check_every_days: 3
has_exiftool: 1
share_button_visible: 0
import_via_symlink: 0
has_ffmpeg: 1
location_decoding: 0
location_decoding_timeout: 30
location_show: 1
location_show_public: 0
rss_enable: 1
rss_recent_days: 7
rss_max_items: 100
prefer_available_xmp_metadata: 0
editor_enabled: 1
lossless_optimization: 0
swipe_tolerance_x: 150
swipe_tolerance_y: 250
local_takestamp_video_formats: .avi|.mov
log_max_num_line: 1000
unlock_password_photos_with_url_param: 0
nsfw_visible: 1
nsfw_blur: 0
nsfw_warning: 0
nsfw_warning_admin: 0
nsfw_banner_override:
map_display_direction: 1
album_subtitle_type: oldstyle
upload_processing_limit: 4
new_photos_notification: 0
legacy_id_redirection: 1
zip_deflate_level: 6
SA_enabled: 1
default_album_protection: 1
allow_username_change: 1
album_decoration: all
album_decoration_orientation: row
auto_fix_orientation: 1
use_job_queues: 0
random_album_id: starred
use_last_modified_date_when_no_exif_date: 0
ffmpeg_path: /usr/bin/ffmpeg
ffprobe_path: /usr/bin/ffprobe
layout: justified
date_format_photo_thumb: M j, Y, g:i:s A e
date_format_photo_overlay: M j, Y, g:i:s A e
date_format_sidebar_uploaded: M j, Y, g:i:s A e
date_format_sidebar_taken_at: M j, Y, g:i:s A e
date_format_hero_min_max: F Y
date_format_hero_created_at: M j, Y, g:i:s A T
date_format_album_thumb: M Y
upload_chunk_size: 0
nsfw_banner_blur_backdrop: 0
search_pagination_limit: 1000
search_minimum_length_required: 4
photo_layout_justified_row_height: 320
photo_layout_masonry_column_width: 300
photo_layout_grid_column_width: 250
photo_layout_square_column_width: 200
photo_layout_gap: 12
display_thumb_album_overlay: always
display_thumb_photo_overlay: hover
Browser and system
- Using Brave, but this will occur in any browser ;)
- Running in Docker
- Debian 11 host
Workaround
Downgrading to version v5.0.2 worked just fine, full site functionality restored.
sed: cannot rename /conf/sedzNSKsq: Device or resource busy
SQLSTATE[HY000] [1044] Access denied for user 'lychee'@'%' to database '/va
r/www/html/Lychee/database/database.sqlite'
It looks like there may be an issue with your /conf volume, though it does seem able to access it once it's running to get the settings for diagnostics.
I have set up a minimal working example of the issue here: trailfog/lychee-migration-issue
I can reproduce the issue~ish with your MWE but ... I noticed that when I do the way I update myself :
docker compose down
# edit to change tag.
docker compose pull
docker compose up -d
It works totally fine on my prod and with your MWE it brings me back to re-install step (I guess there are no SQL persistence in your docker compose).
It works totally fine on my prod and with your MWE it brings me back to re-install step (I guess there are no SQL persistence in your docker compose).
You are correct, that my minimal setup does not use persistence, as I was not tearing down the entire setup. I have updated my example repo with a volume to make the DB persistent.
Running your exact commands unfortunately still gives me the same upgrade error.
It looks like there may be an issue with your
/confvolume, though it does seem able to access it once it's running to get the settings for diagnostics.
@d7415 I disabled write access to the conf file during the upgrade to v5, basically to eliminate the lychee setup from messing with my config.
I should have posted the diagnostics from the MWE and not those from my actual server to avoid some confusion.
Found it. That is because the cli does not have the environment variables to run the migration. if you add DB_HOST etc (as below) it will work.
lychee:
image: lycheeorg/lychee:v5.1.0
container_name: lychee
ports:
- 8080:80
networks:
- backend
volumes:
- ./lychee/.env:/conf/.env
environment:
- PUID=1000
- PGID=100
- STARTUP_DELAY=5
- DB_CONNECTION=mysql
- DB_HOST=mariadb
- DB_PORT=3306
- DB_DATABASE=lychee
- DB_USERNAME=lychee
- DB_PASSWORD=supersecret
I can confirm that this fixed it on my side as well.
In fact, only the DB_CONNECTION=mysql env variable needed to be set.
Thanks for your help @ildyria
Maybe as a suggestion, the README of the lychee-Docker repo should probably include a note that the DB_CONNECTION env variable must be set, regardless if it has been set in the config file.
Currently, it only states, that lychee may be configured from an env file or the env variables.
Thanks for your help @ildyria
My pleasure. :)
Maybe as a suggestion, the README of the lychee-Docker repo should probably include a note that the
DB_CONNECTIONenv variable must be set, regardless if it has been set in the config file. Currently, it only states, that lychee may be configured from an env file or the env variables.
Feel free to open a pull request too :)
Found it. That is because the cli does not have the environment variables to run the migration.
Shouldn't it be getting that from .env? Otherwise how does it work for non-Docker installations?
It seems to me, that this line is the culprit of (my) problems.
If the $DB_CONNECTION variable is either sqlite or not set/zero length, it will choose sqlite, irrelevant of what has been configured in the env file.
Probably it is better to fix that line than to update the readme with a workaround.
If the
$DB_CONNECTIONvariable is eithersqliteor not set/zero length, it will choose sqlite, irrelevant of what has been configured in the env file.
That's somewhat required to handle the default case, but yes, it does set DB_DATABASE. From testing (ages ago) this was fine for the installer, but it's possible Laravel will choose that value over what's in .env. Which isn't especially helpful in this case.