Closed dbrandesky closed 2 years ago
Although I think it is unrelated, you should fix the warning about the invalid timezone.
I tried it on current master and it worked as expected. I could not reproduce the problem. Could you clean the logs, try again and post the log output here? The logs should tell more what goes wrong. You find the logs in the left menu (with the cog symbol) below the item "Show logs".
At the moment, I would assume that it could still be a problem with the server configuration. Even if access rights are fine and even if you can use cat
on the image from an interactive user shell, the PHP process still might be chroot
ed or something similar which prevents creating links.
Although I think it is unrelated, you should fix the warning about the invalid timezone.
Yes, that’s next on my list to tackle.
I tried it on current master and it worked as expected. I could not reproduce the problem. Could you clean the logs, try again and post the log output here? The logs should tell more what goes wrong. You find the logs in the left menu (with the cog symbol) below the item "Show logs".
At the moment, I would assume that it could still be a problem with the server configuration. Even if access rights are fine and even if you can use
cat
on the image from an interactive user shell, the PHP process still might bechroot
ed or something similar which prevents creating links.
I’m thinking file permissions may be the issue too but I haven’t found the correct resolution yet.
Here’s the relevant logs from the most recent attempt:
2022-05-08 20:42:24 UTC -- error -- App\Actions\Import\Exec::do -- 313 -- Attempt to read property "id" on null 2022-05-08 20:42:24 UTC -- error -- App\Actions\Import\Exec::do -- 298 -- Unsupported file type 2022-05-08 20:42:21 UTC -- error -- App\Actions\Import\Exec::do -- 298 -- Unsupported file type 2022-05-08 20:42:17 UTC -- error -- App\Actions\Import\Exec::do -- 298 -- Unsupported file type 2022-05-08 20:42:14 UTC -- error -- App\Actions\Import\Exec::do -- 298 -- Unsupported file type
The “unsupported file type” messages are because of some zip archives I have in the root directory of my photo folder.
When using symlinks, does the process running Lychee/PHP need write access to the photo directory? I’ve added the www user to a group that has write access to the directory on the host system, but I’m still running into the same error.
I assume you just triggered a silly bug. The failing line is
->where('albums.parent_id', '=', $parentAlbum->id)
If the parent album is the root album, then $parentAlbum
equals null
and so the property id
cannot be read. That's what the error message is telling us.
I assume you try to import into the root album? Can you confirm that? I bet, the error does not occur, if you import into a sub-album.
Nonetheless, the fix is easy. The line should be
->where('albums.parent_id', '=', $parentAlbum?->id)
(Note the additional question mark.) I am not in front of a computer to fix that right now. But you can also do that locally in your installation.
When using symlinks, does the process running Lychee/PHP need write access to the photo directory?
No, Lychee/PHP does not require write access to the folder to which the symbolic links point to.
I don't think that the bug is related to symbolic links at all. I guess the bug is triggered because you try to import a tree of directories into the root level. I assume the bug would also be triggered without using symbolic links.
Modifying
$parentAlbum
to$parentAlbum?
resolved the issue. I created a local branch with my change but I admit I'm not super experienced with contributing to github so I'm not sure how to contribute my change to the project.
We have an instruction page for this: https://lycheeorg.github.io/docs/contributions.html#illustrated-example. It uses GitHub's web editor, but since you only have a single line to change that should be fine :)
Never mind, I have already pushed a fix and cleaned up an exception, too.
Detailed description of the problem [REQUIRED]
Importing a folder using symlinks fails due to a Laravel error: "Attempt to read property "id" on null"
Steps to reproduce the issue
Steps to reproduce the behavior:
Output of the diagnostics [REQUIRED]
`php artisan lychee:diagnostics PHP Warning: date(): Invalid date.timezone value 'mytimezone', we selected the timezone 'UTC' for now. in /usr/local/www/Lychee/config/app.php on line 81
Diagnostics
Warning: Dropbox import not working. dropbox_key is empty. Info: Latest version of PHP is 8.1
System Information
Lychee Version (git): master (50dacef) -- - 2 commits behind master 7d27f7d (12 minutes ago) DB Version: 4.5.1
composer install: --no-dev APP_ENV: production APP_DEBUG: false
System: FreeBSD PHP Version: 8 PHP User agent: Lychee/4 (https://lycheeorg.github.io/) Timezone: America/Detroit Max uploaded file size: 16G Max post size: 16G Max execution time: 0 MySQL Version: 10.3.34-MariaDB
Imagick: 1 Imagick Active: 1 Imagick Version: 1692 GD Version: 2.3.3
Config Information
version: 040501 check_for_updates: 0 sorting_photos_col: taken_at sorting_photos_order: ASC sorting_albums_col: max_taken_at 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 layout: 1 image_overlay_type: desc default_license: none compression_quality: 90 full_photo: 1 delete_imported: 0 Mod_Frame: 1 Mod_Frame_refresh: 30 thumb_2x: 1 small_2x: 1 medium_2x: 1 landing_page_enable: 0 landing_owner: John Smith landing_title: John Smith landing_subtitle: Cats, Dogs & Humans Photography landing_facebook: https://www.facebook.com/JohnSmith landing_flickr: https://www.flickr.com/JohnSmith landing_twitter: https://www.twitter.com/JohnSmith landing_instagram: https://instagram.com/JohnSmith landing_youtube: https://www.youtube.com/JohnSmith landing_background: dist/cat.jpg site_title: Lychee v4 site_copyright_enable: 1 site_copyright_begin: 2019 site_copyright_end: 2019 additional_footer_text:
display_social_in_gallery: 0 public_search: 0 SL_enable: 0 SL_for_admin: 0 public_recent: 0 recent_age: 1 public_starred: 0 downloadable: 0 photos_wraparound: 1 map_display: 0 zip64: 1 map_display_public: 0 map_provider: Wikimedia force_32bit_ids: 0 map_include_subalbums: 0 update_check_every_days: 3 has_exiftool: 0 share_button_visible: 0 import_via_symlink: 0 has_ffmpeg: 0 location_decoding: 0 location_decoding_timeout: 30 location_show: 1 location_show_public: 0 rss_enable: 0 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 map_display_direction: 1 album_subtitle_type: oldstyle upload_processing_limit: 4 public_photos_hidden: 1 new_photos_notification: 0 legacy_id_redirection: 1`
Browser and system
Chromium Version 99.0.4844.82 (openSUSE Build) stable (64-bit) Server: TrueNAS 12.0-U8 iocage/jail (FreeBSD 12.3)
Additional details
Hi all, I'm running Lychee in a Jail on a TrueNAS system (FreeBSD-based) using this script for setup. Lychee is up and running and appears to be healthy. I added a mount to my iocage/jail containing Lychee in order to access some of my photos on the local storage pools. I ensured that the user running the jail/iocage is in a group with the same GID as the GID used for my photos on the host system, and I have confirmed that I can "cat" my photos from within the jail/iocage without issue, so I'm pretty sure file permissions are good.
Despite this, when I attempt to add the location to Lychee, it quickly returns the error shown in the title of this issue. This appears to be a Laravel issue which I have no idea how to address. I don't see any other errors returned so I don't really have anything else go to on.
FWIW, I'm importing the location using symlinks as I don't want to duplicate my entire photo library. If I don't use symlinks, I don't have any problems.