Possible file/dir perms mismatch

[rikkoenig]

Lychee version

v7.3.2

Did you check the latest Lychee version?

Yes, I did

Which PHP version are you using?

PHP 8.5

Detailed description of the problem

Testing upgrade from 6.x to 7.x on Kubernetes 1.34

When looking at diagnostics, I see a warning that certain directories have perms of 0755, and should have 0775. Manually changing dir perms to 0775 does make the warning disappear.

Warning: /*********c/uploads/ has permissions 0755, but should have 0775

I examined the 05-permissions-check.sh script, and lines 48-49 set the perms to 755.

  find /app/public/uploads -type d \( ! -perm 755 \) -exec chmod 755 {} + 2>/dev/null || true
  find /app/public/dist -type d \( ! -perm 755 \) -exec chmod 755 {} + 2>/dev/null || true

Which is the correct, intended permission set?

Related: got warning on dir group-ownership, complaining it should be root, and the script sets www-data in lines 44-45 of the same script

Warning: /*********c/uploads/ is owned by group www-data, but should be owned by one out of root

Steps to reproduce the issue

Visit diagnostics page after application start

Diagnostics [REQUIRED]

Smart Diagnostics
-----------------
Info: Hash: 312792fb4db3b834—dc0bb07f48a6135e
         2581 files and 14015 vendor files
Info: Full directory permission check is disabled
Warning: Default timezone not properly set; you might experience strange results when importing photos without explicit EXIF timezone
Info: Found 23 placeholders that could be generated.
         You can use `php artisan lychee:generate_thumbs placeholder 23` to generate them.
Info: Have you considered supporting Lychee? :)

System Information
------------------
Lychee Version (release):                  7.3.2
DB Version:                                7.3.2

Docker:                                    false
composer install:                          --no-dev
APP_ENV:                                   production
APP_DEBUG:                                 false
APP_URL:                                   set
APP_DIR:                                   default
LOG_VIEWER_ENABLED:                        true

System:                                    Linux
PHP Version:                               8.5.1
PHP User agent:                            Lychee/6 (https://lycheeorg.dev/)
Timezone:                                  Etc/UTC
Max uploaded file size:                    128M
Max post size:                             128M
Chunk size:                                102.40 MB
Max execution time:                        0
MySQL Version:                             11.8.3-MariaDB-ubu2404

exec() Available:                          yes
Imagick Available:                         1
Imagick Enabled:                           yes
Imagick Version:                           1809
GD Version:                                bundled (2.1.0 compatible)
Number of foreign key:                     33 found.

Browser & System [REQUIRED]

Browser: Zen
System: Kubernetes 1.34

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.

[rikkoenig]

Double-checked on 7.3.3. This is after upgrade from 7.3.2 to 7.3.3:

Warning: /*********c/uploads/ is owned by group www-data, but should be owned by one out of root
Warning: /*********c/uploads/ has permissions 0755, but should have 0775
Warning: /a********ge/tmp/jobs/ has permissions 0700, but should have 0775
Warning: /a********ge/tmp/uploads/ has permissions 0700, but should have 0775

[ildyria]

Warning: /*********c/uploads/ is owned by group www-data, but should be owned by one out of root

Are you running the container as root ? Because in the later versions (7.3+) the PUID and GUID allows you to select the user to make it match.

For the 755 etc... I will double check if I can make those verifications a bit more lax.