Permission denied on file import

[nitobuendia]

I do not think this is a bug, but I couldn't find a better place for support. This is clearly a permission issue on the upload folder, but I've tried a few ways of setting chown and chmod 755 without avail.

Detailed description of the problem [REQUIRED]

When trying to Import [pictures] from server, the system detects the pictures but fails to import with "Could not import the file!". Logs shows that this is a permission issue on the uploads folder.

Steps to reproduce the issue

Steps to reproduce the behavior:

1. Go to UI
2. Click on '+' > Import from Server
3. Files are read from the different folder but fails to import with "Could not import the file!".

Output of the diagnostics [REQUIRED]

Info: Latest version of PHP is 8

System Information
------------------
Lychee Version (git):            No git data found.
DB Version:                      4.3.6

composer install:                --no-dev
APP_ENV:                         production
APP_DEBUG:                       false

System:                          Linux
PHP Version:                     7.4
Max uploaded file size:          2M
Max post size:                   8M
MySQL Version:                   10.6.5-MariaDB-1:10.6.5+maria~focal

Imagick:                         1
Imagick Active:                  1
Imagick Version:                 1691
GD Version:                      2.3.0

Config Information
------------------
version:                         040306
check_for_updates:               0
sorting_Photos_col:              taken_at
sorting_Photos_order:            ASC
sorting_Albums_col:              title
sorting_Albums_order:            DESC
imagick:                         1
skip_duplicates:                 1
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:                   Nito Buendia
landing_title:                   Nito Buendia
landing_subtitle:                
landing_facebook:                
landing_flickr:                  
landing_twitter:                 
landing_instagram:               
landing_youtube:                 
landing_background:              
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:                     1
zip64:                           1
map_display_public:              0
map_provider:                    Wikimedia
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:               1
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

Troubleshooting and details

Docker configuration

Running on Docker on Ubuntu. docker-compose.yaml

version: "3"

services:
  lychee:
    image: lycheeorg/lychee
    container_name: lychee
    restart: unless-stopped
    ports:
      - 6980:80
    volumes:
      - ./config:/conf
      - /mnt/nas/Streaming/Lychee/uploads:/uploads
    env_file:
      - ./secrets.env
    environment:
      - TZ=Asia/Singapore
      - PHP_TZ=Asia/Singapore

/mnt/nas/Streaming/Lychee/uploads is a cifs mounted folder, but this never caused any issues. I already have a lot of pictures imported in the past. I can also touch files there from the host of docker and also through the container with docker exec -ti lychee touch /uploads/import/a.txt

Lychee PHP logs

docker exec -ti lychee php artisan lychee:logs

2022-01-06 19:57:54 -- error   -- App\Actions\Import\Exec::do -- 256 -- Could not import file (/var/www/html/Lychee/public/uploads/import/2021 - First Computer Build/VID_20211020_201222.mp4)
2022-01-06 19:57:54 -- error   -- App\Actions\Photo\Extensions\Checks::checkPermissions -- 27 -- An upload-folder is missing or not readable and writable
2022-01-06 19:57:54 -- error   -- App\Actions\Photo\Extensions\Checks::checkPermissions -- 29 -- Error: '/var/www/html/Lychee/public/uploads/big' is missing or has insufficient read/write privileges
2022-01-06 19:57:54 -- error   -- App\Actions\Photo\Extensions\Checks::checkPermissions -- 29 -- Error: '/var/www/html/Lychee/public/uploads/medium' is missing or has insufficient read/write privileges
2022-01-06 19:57:55 -- error   -- App\Actions\Photo\Extensions\Checks::checkPermissions -- 29 -- Error: '/var/www/html/Lychee/public/uploads/small' is missing or has insufficient read/write privileges
2022-01-06 19:57:55 -- error   -- App\Actions\Photo\Extensions\Checks::checkPermissions -- 29 -- Error: '/var/www/html/Lychee/public/uploads/thumb' is missing or has insufficient read/write privileges
2022-01-06 19:57:55 -- error   -- App\Actions\Photo\Extensions\Checks::checkPermissions -- 29 -- Error: '/var/www/html/Lychee/public/uploads/import' is missing or has insufficient read/write privileges
2022-01-06 19:57:55 -- error   -- App\Actions\Photo\Extensions\Checks::checkPermissions -- 29 -- Error: '/var/www/html/Lychee/public/uploads/' is missing or has insufficient read/write privileges
2022-01-06 19:57:55 -- error   -- App\Actions\Import\Exec::do -- 256 -- Could not import file (/var/www/html/Lychee/public/uploads/import/2021 - First Computer Build/VID_20211020_201421.mp4)

This repeates for every file. This is clearly a permissions issue. However, there are no issues on startup:

Startup logs

docker logs lychee

-------------------------------------
  _               _                
 | |   _   _  ___| |__   ___  ___  
 | |  | | | |/ __|  _ \ / _ \/ _ \ 
 | |__| |_| | (__| | | |  __/  __/ 
 |_____\__, |\___|_| |_|\___|\___| 
 | |   |___/ _ __ __ ___   _____| |
 | |   / _' | '__/ _' \ \ / / _ \ |
 | |__| (_| | | | (_| |\ V /  __/ |
 |_____\__,_|_|  \__,_| \_/ \___|_|

-------------------------------------
Lychee Version: 4.3.6 (release)
Lychee Commit:  e86652f
https://github.com/LycheeOrg/Lychee/commit/e86652f27fffe67cfa20c99e10aac01b28a1b9c8
-------------------------------------
**** Make sure the /conf and /uploads folders exist ****
**** Create the symbolic link for the /uploads folder ****
**** Create the symbolic link for the /sym folder ****
**** Create the symbolic link to the old Lychee-Laravel folder ****
**** Copy the .env to /conf ****
**** Inject .env values ****
**** Generate the key (to make sure that cookies cannot be decrypted etc) ****

**************************************
*     Application In Production!     *
**************************************

Command Canceled!
**** Migrate the database ****

Nothing to migrate.
**** Check user.css exists and symlink it ****
**** Create user and use PUID/PGID ****
        User UID :      1000
        User GID :      1000
**** Set Permissions ****
**** Setup complete, starting the server. ****

Permissions (ls)

docker exec -ti lychee ls -la /var/www/html/Lychee/public/

(...) lrwxrwxrwx 1 root root 8 Jan 6 19:52 uploads -> /uploads

I understand that this a symlink to the root /uploads folder, so checking the permissions there.

docker exec -ti lychee ls -la /uploads

drwxr-xr-x 2 lychee root    0 Jan  6 19:14 .
drwxr-xr-x 1 root   root 4096 Jan  6 19:52 ..
-rwxr-xr-x 1 lychee root 6148 Jan  6 19:44 .DS_Store
drwxr-xr-x 2 lychee root    0 Jan 17  2021 big
drwxr-xr-x 2 lychee root    0 Jan  6 19:53 import
drwxr-xr-x 2 lychee root    0 Jan 17  2021 medium
drwxr-xr-x 2 lychee root    0 Jan 16  2021 raw
drwxr-xr-x 2 lychee root    0 Jan 17  2021 small
drwxr-xr-x 2 lychee root    0 Jan 17  2021 thumb

If I understand correctly, this is owned by lychee and www-data is added to lychee.

I've tried running docker exec -ti lychee /bin/bash and chown -R www-data /var/www/html/Lychee/public/uploads/ but it didnt' seem to help or change it. Similar for chmod 755 -R /var/www/html/Lychee/public/uploads/

How should I adjust the permissions so the import works?

Browser and system

Server: Docker + Lychee Version: 4.3.6 (release) Client: Chrome 96.0.4664.110 on macOS Big Sur 11.6 - but this is not a client issue

[d7415]

drwxr-xr-x 2 lychee root 0 Jan 6 19:14 .

The entrypoint script shouldn't leave them like this..

If I understand correctly, this is owned by lychee and www-data is added to lychee.

You're half right. www-data in the container is a member of the lychee group, but those folders only have permissions for the lychee user, not the group. They need to be owned by lychee:lychee, which the entrypoint script should handle.

Have you changed the permissions since it's been running?

[nitobuendia]

Thank you @d7415 for your thoughts and insights.

The entrypoint script shouldn't leave them like this. [and] which the entrypoint script should handle.

That's my thought too. However, it doesn't seem to do it. I've restarted (docker-compose down && docker-compse up -d) the container a few times and the same results. There's also no errors on startup as you can see on my post (perhaps it's a silent error?).

Have you changed the permissions since it's been running?

I did not. At least not myself. It started failing on its own without any changes from my side. When I was troubleshooting, I did try using chown and chmod to fix the issue, but it didn't work. It never changed the permissions (see below). Also, I never assigned the root group only www-data and lychee. I've also done the container restart above after I did (so even if I changed them, it should have taken care of it).

those folders only have permissions for the lychee user, not the group.

Doing chown lychee:lychee on the folders from docker exec -ti lychee /bin/bash does not seem to work.

uploads# chown lychee:lychee import
uploads# ls -la
total 12
drwxr-xr-x 2 lychee root    0 Jan  6 19:14 .
drwxr-xr-x 1 root   root 4096 Jan  6 19:52 ..
-rwxr-xr-x 1 lychee root 6148 Jan  6 21:55 .DS_Store
drwxr-xr-x 2 lychee root    0 Jan 17  2021 big
drwxr-xr-x 2 lychee root    0 Jan  6 20:19 import
drwxr-xr-x 2 lychee root    0 Jan 17  2021 medium
drwxr-xr-x 2 lychee root    0 Jan 16  2021 raw
drwxr-xr-x 2 lychee root    0 Jan 17  2021 small
drwxr-xr-x 2 lychee root    0 Jan 17  2021 thumb

This might be related to the problem. If I cannot change the permissions through /bin/bash, perhaps the original script cannot change them either. I've also tried chgrp -R lychee uploads but did not seem to work either.

Changing chmod does not seem to throw any errors:

docker exec -ti lychee chmod -Rv ug+w,ugo+rX /uploads outputs mode of '/uploads/medium/322c3e1430098da009f419b447f2648b.jpg' changed from 0755 (rwxr-xr-x) to 0775 (rwxrwxr-x) for all files and folders.

Same goes for chown command:

docker exec -ti lychee chown -Rv lychee:lychee /uploads outputs changed ownership of '/uploads' from lychee:root to lychee:lychee for all files and folders.

However, they do not seem to be reflected:

docker exec -ti lychee ls -la /uploads
total 12
drwxr-xr-x 2 lychee root    0 Jan  6 19:14 .
drwxr-xr-x 1 root   root 4096 Jan  6 19:52 ..
-rwxr-xr-x 1 lychee root 6148 Jan  6 21:55 .DS_Store
drwxr-xr-x 2 lychee root    0 Jan 17  2021 big
drwxr-xr-x 2 lychee root    0 Jan  6 20:19 import
drwxr-xr-x 2 lychee root    0 Jan 17  2021 medium
drwxr-xr-x 2 lychee root    0 Jan 16  2021 raw
drwxr-xr-x 2 lychee root    0 Jan 17  2021 small
drwxr-xr-x 2 lychee root    0 Jan 17  2021 thumb

[d7415]

Yeah, that's starting to sound like CIFS not handling the group ownership properly.

It might work if you rerun it with USER=www-data in the environment section of your config. I haven't had time to test (and only have passing familiarity with docker-compose), but at a glance, that should change the ownership to www-data, which would grant the required permissions.

[nitobuendia]

I need more time to troubleshoot on my side, but a quick update.

Running with USER=www-data on the docker-composer.yaml environment section achieved this:

1. User permissions were changed, but group permissions were still not changed.

drwxr-xr-x 2 www-data root    0 Jan  6 19:14 .
drwxr-xr-x 1 root     root 4096 Jan  9 22:31 ..
-rwxr-xr-x 1 www-data root 6148 Jan  6 21:55 .DS_Store
drwxr-xr-x 2 www-data root    0 Jan 17  2021 big
drwxr-xr-x 2 www-data root    0 Jan  9 22:31 import
drwxr-xr-x 2 www-data root    0 Jan 17  2021 medium
drwxr-xr-x 2 www-data root    0 Jan 16  2021 raw
drwxr-xr-x 2 www-data root    0 Jan 17  2021 small
drwxr-xr-x 2 www-data root    0 Jan 17  2021 thumb

2. However, the app failed to load with: 503 ../storage and sub-directories are not writable. Please set the proper access rights. - I probably can troubleshoot this a little bit more.

If I were to remove the line and revert back to without the user, it would change the user permissions back to lychee:

drwxr-xr-x 2 lychee root    0 Jan  6 19:14 .
drwxr-xr-x 1 root   root 4096 Jan  9 22:49 ..
-rwxr-xr-x 1 lychee root 6148 Jan  6 21:55 .DS_Store
drwxr-xr-x 2 lychee root    0 Jan 17  2021 big
drwxr-xr-x 2 lychee root    0 Jan  9 22:31 import
drwxr-xr-x 2 lychee root    0 Jan 17  2021 medium
drwxr-xr-x 2 lychee root    0 Jan 16  2021 raw
drwxr-xr-x 2 lychee root    0 Jan 17  2021 small
drwxr-xr-x 2 lychee root    0 Jan 17  2021 thumb

So, I assume the problem here is an issue on assigning those group permissions. The proposed fix may still work if I can fix the storage permissions, though, which I can try troubleshooting later this week. I guess adding www-data user to root group may work too, although not sure if that's what I'd go with. I'll check also the mount configuration in case there's something about the group. Although other containers mounted on the same path (/mnt/nas/Streaming/) can read and write without any issues.

Thanks again, @d7415

[nitobuendia]

I've had some time to troubleshoot a few things and sharing here:

Related Issues

Potentially related or the same as #75 - the path is on a Synology NAS drive mounted on Ubuntu. This has worked in the past, but the issue seems quite similar to what's described there, though.

Starting container on NAS [workaround]

I temporarily moved the docker from my server to the Synology NAS (where the upload folder actually exists vs mounted), the permissions propagated correctly (i.e. lychee:lychee for all files) and I was able to upload the pictures.

This makes me thing that the either (a) the CIFS mount is the root cause here, or (b) something else has happened in the container and now it's not working properly. A quick way to verify (b) is to try to fully remove the container on the server and install it again.

Removing Container [potential solution, but didn't manage to make it work]

I haven't been able to achieve (b). I did docker-compose down -v, went to portainer and removed both the image as well any annonymous volumes. Upon reinstall, the container was ready to go (compared to NAS where it went through install process despite being the same set up) and the permissions where still lychee:root. I am sure I am missing something here, so more work potentially needed.

CIFS Troubleshooting [potential root cause, but no solution]

I am not sure if this is really the root cause or if there's a way to fix that. I do know that this used to work before and other containers do not have the same issue, thoguh.

Running with www-data [potential bug]

Running with www-data starts the app with 503 ../storage and sub-directories are not writable. Please set the proper access rights.. Checking docker exec -ti lychee ls -la ./storage returns this:

total 28
drwxr-xr-x 6 33 33 4096 Nov 24 02:41 .
drwxr-xr-x 1 33 33 4096 Jan 11 21:55 ..
drwxr-xr-x 3 33 33 4096 Nov 24 02:41 app
drwxr-xr-x 2 33 33 4096 Nov 24 02:41 debugbar
drwxr-xr-x 6 33 33 4096 Nov 24 02:41 framework
drwxr-xr-x 2 33 33 4096 Nov 24 02:41 logs

It seems that instead of assigning the ownership to www-data, it assigns it to its id.

This does not happen when starting it without USER=www-data on environment.

drwxr-xr-x 6 www-data www-data 4096 Nov 24 02:41 .
drwxr-xr-x 1 www-data www-data 4096 Jan 11 22:03 ..
drwxr-xr-x 3 www-data www-data 4096 Nov 24 02:41 app
drwxr-xr-x 2 www-data www-data 4096 Nov 24 02:41 debugbar
drwxr-xr-x 6 www-data www-data 4096 Nov 24 02:41 framework
drwxr-xr-x 2 www-data www-data 4096 Nov 24 02:41 logs

Could this be a bug even if not fully related to the issue at hand?

[d7415]

Running with www-data [potential bug]

Ah. I think I've figured this one out (though I haven't tested it).

• We don't change the permissions of storage after the Docker image is created. This was my clue.
• The entrypoint script forces the UID and GID to 1000 unless set in the environment (I suspect to make things work better with the parent system)
• In this case, it actually changes www-data's UID to 1000, so that the pre-existing permissions no longer apply.
• It's possible that using USER=www-data, PUID=33, PGID=33 would work as originally intended. Again, untested.

[nitobuendia]

@d7415 That makes sense, and it solved the storage issue, yes. Although there's still something funky going on.

USER=www-data, PUID=33, PGID=33

docker-compose.yaml

version: "3"

services:
  lychee:
    image: lycheeorg/lychee
    container_name: lychee
    restart: unless-stopped
    ports:
      - 6980:80
    volumes:
      - ./config:/conf
      - /mnt/nas/Streaming/Lychee/uploads:/uploads
    env_file:
      - ./secrets.env
    environment:
      - TZ=Asia/Singapore
      - PHP_TZ=Asia/Singapore
      - USER=www-data
      - PUID=33
      - PGID=33

Permissions are fine now in storage, but in exchange, they remained as lychee on the /uploads folder (and therefore the issue persists).

nito@nito-server:/mnt/ssd/docker/lychee$ docker exec -ti lychee ls -la /uploads
total 12
drwxr-xr-x 2 lychee root    0 Jan  6 19:14 .
drwxr-xr-x 1 root   root 4096 Jan 12 18:58 ..
-rwxr-xr-x 1 lychee root 6148 Jan 12 18:54 .DS_Store
drwxr-xr-x 2 lychee root    0 Jan 11 23:08 big
drwxr-xr-x 2 lychee root    0 Jan 12 18:56 import
drwxr-xr-x 2 lychee root    0 Jan 11 22:50 medium
drwxr-xr-x 2 lychee root    0 Jan 16  2021 raw
drwxr-xr-x 2 lychee root    0 Jan 11 23:08 small
drwxr-xr-x 2 lychee root    0 Jan 11 23:08 thumb
nito@nito-server:/mnt/ssd/docker/lychee$ docker exec -ti lychee ls -la ./storage
total 28
drwxr-xr-x 6 www-data www-data 4096 Nov 24 02:41 .
drwxr-xr-x 1 www-data www-data 4096 Jan 12 18:58 ..
drwxr-xr-x 3 www-data www-data 4096 Nov 24 02:41 app
drwxr-xr-x 2 www-data www-data 4096 Nov 24 02:41 debugbar
drwxr-xr-x 6 www-data www-data 4096 Nov 24 02:41 framework
drwxr-xr-x 2 www-data www-data 4096 Nov 24 02:41 logs

USER=www-data

If I remove the PUID=33, and PGID=33 part, the user permissions change fine:

nito@nito-server:/mnt/ssd/docker/lychee$ docker exec -ti lychee ls -la /uploads
total 12
drwxr-xr-x 2 www-data root    0 Jan  6 19:14 .
drwxr-xr-x 1 root     root 4096 Jan 12 19:04 ..
-rwxr-xr-x 1 www-data root 6148 Jan 12 18:54 .DS_Store
drwxr-xr-x 2 www-data root    0 Jan 11 23:08 big
drwxr-xr-x 2 www-data root    0 Jan 12 18:56 import
drwxr-xr-x 2 www-data root    0 Jan 11 22:50 medium
drwxr-xr-x 2 www-data root    0 Jan 16  2021 raw
drwxr-xr-x 2 www-data root    0 Jan 11 23:08 small
drwxr-xr-x 2 www-data root    0 Jan 11 23:08 thumb

except for the aformentioned issue on ./storage

total 28
drwxr-xr-x 6 33 33 4096 Nov 24 02:41 .
drwxr-xr-x 1 33 33 4096 Jan 12 19:04 ..
drwxr-xr-x 3 33 33 4096 Nov 24 02:41 app
drwxr-xr-x 2 33 33 4096 Nov 24 02:41 debugbar
drwxr-xr-x 6 33 33 4096 Nov 24 02:41 framework
drwxr-xr-x 2 33 33 4096 Nov 24 02:41 logs

USER=lychee, PUID=33, PGID=33

I tried to assing lychee to userId 33. This seems to have a similar but opposite problem to what we saw before.

nito@nito-server:/mnt/ssd/docker/lychee$ docker exec -ti lychee ls -la ./storage
total 28
drwxr-xr-x 6 www-data www-data 4096 Nov 24 02:41 .
drwxr-xr-x 1 www-data www-data 4096 Jan 12 19:06 ..
drwxr-xr-x 3 www-data www-data 4096 Nov 24 02:41 app
drwxr-xr-x 2 www-data www-data 4096 Nov 24 02:41 debugbar
drwxr-xr-x 6 www-data www-data 4096 Nov 24 02:41 framework
drwxr-xr-x 2 www-data www-data 4096 Nov 24 02:41 logs
nito@nito-server:/mnt/ssd/docker/lychee$ docker exec -ti lychee ls -la /uploads
total 12
drwxr-xr-x 2 1000 root    0 Jan  6 19:14 .
drwxr-xr-x 1 root root 4096 Jan 12 19:06 ..
-rwxr-xr-x 1 1000 root 6148 Jan 12 18:54 .DS_Store
drwxr-xr-x 2 1000 root    0 Jan 11 23:08 big
drwxr-xr-x 2 1000 root    0 Jan 12 18:56 import
drwxr-xr-x 2 1000 root    0 Jan 11 22:50 medium
drwxr-xr-x 2 1000 root    0 Jan 16  2021 raw
drwxr-xr-x 2 1000 root    0 Jan 11 23:08 small
drwxr-xr-x 2 1000 root    0 Jan 11 23:08 thumb

This seems to mean that /uploads permissions are actually not changing.

The permissions of /uploads are set to 1000:root and the ones in ./storage are set to 33:33. This is what I think it's happening"

• USER=www-data,PUID=33,PGID=33 --> this keeps www-data as 33 and lychee as 1000; which is why storage is owned by www-data (33) and uploads by lychee (1000).
• USER=www-data --> this makes www-data as 1000. As a result, there's no user 33; which is why uploads is owned by www-data (1000) but storage is broken as it's owned by 33 and there's no such user.
• USER=lychee,PUID=33,PGID=33 --> this makes lychee to be 33 and (assumption) at some point we reassign www-data to be 33. As a result, storage is owned by www-data (33) but there's no owner for uploads since there's no longer a user 1000.
• When no input --> lychee is 1000 and www-data is kept as 33; as such, uploads is owned by lychee (1000) and storage by www-data (33).

If this is correct, I think the underlying and clear problem is that the permissions within the container are not changing. The question is why would that be happening. Hypotheses before are: #75, the CIFS mount or an issue at the container (which a clean remove should fix but not sure how to execute it properly).

[d7415]

That is very weird.

• USER=www-data,PUID=33,PGID=33 --> this keeps www-data as 33 and lychee as 1000;

That is my understanding. It should output the UID/GID on startup (from entrypoint) but that shouldn't be necessary.

which is why storage is owned by www-data (33) and uploads by lychee (1000).

Yes to the first, but the uploads should change. But yes.

* USER=www-data --> this makes www-data as 1000. As a result, there's no user 33; which is why uploads is owned by www-data (1000) but storage is broken as it's owned by 33 and there's no such user.

Agreed.

* USER=lychee,PUID=33,PGID=33 --> this makes lychee to be 33 and (assumption) at some point we reassign www-data to be 33. As a result, storage is owned by www-data (33) but there's no owner for uploads since there's no longer a user 1000.

www-data still has ID 33 - the ID change cheats and tells usermod (and groupmod) that the ID doesn't have to be unique, so www-data and lychee are both UID/GID 33. But the uploads should still be changed. Maybe the non-unique ID breaks it and it fails silently?

If this is correct, I think the underlying and clear problem is that the permissions within the container are not changing. The question is why would that be happening. Hypotheses before are: #75, the CIFS mount or an issue at the container (which a clean remove should fix but not sure how to execute it properly).

It seems that way, but as they are being changed by one of your examples I'm not sure. My best guess is a silent chown failure as suggested above. This is all very odd though.

Aside: This has led me to find a minor bug (not relevant - the lychee group name was hard coded for user.css) so that's something.

[nitobuendia]

Aside: This has led me to find a minor bug (not relevant - the lychee group name was hard coded for user.css) so that's something.

That's great :) - at least something useful out of this.

---

Question: what are all the permissions that are required for the app to run? What I've puzzled so far (if I read this correctly):

• www-data requires 775 to /conf /uploads /sym

Any other critical permissions? Is ownership required or only read/write?

Context: I was thinking of somehow trying to assing the right permissions manually (not ownership) and seeing if that'd work.

[Archpanda]

Hello, If that might be of any help, I ran into the issue myself, and tried to modify the permissions manually, but I haven't been lucky. It doesnt seem possible to alter the owner of the folders under uploads, but although the right are displayed as 777, the import fails, the logs are very sparse and do not indicated what was trying to be written, nor where.

[nagmat84]

The OP is using an ancient version of Lychee. If this also applies to your installation, please upgrade. The problem should be fixed since 4.5.

You cannot solve this problem by setting directory permission. This ancient version of Lychee uses the PHP rename method to move the uploaded file from the system wide temporary directory into the Lychee path. PHP rename does not work across container boundaries, if the user who runs the Docker container is a different user than the one who runs the webserver and/or who owns the system wide temporary directory. The reason is that PHP rename does not simply map to a POSIX syscall rename, but also attempts to do more like re-setting ownership, etc., which is not allowed.

The recent version of Lychee does not have the problem, because it uses file streams.

[Archpanda]

Ok, thanks for the update. I must have mistaken my problem with this one then, since I'm running on 4.5.3.

[d7415]

Based on @nagmat84's insight, I'm going to close this as the original issue should be fixed.

[nagmat84]

Ok, thanks for the update. I must have mistaken my problem with this one then, since I'm running on 4.5.3.

In this case, please open a new issue and fill out all the requested information: the diagnostic, etc., and also include the logs. Since 4.5 the error reporting has been improved significantly and we should be able to see what line of code is failing.