Closed nitobuendia closed 2 years ago
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?
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
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.
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:
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
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
I've had some time to troubleshoot a few things and sharing here:
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.
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.
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.
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 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?
Running with www-data [potential bug]
Ah. I think I've figured this one out (though I haven't tested it).
storage
after the Docker image is created. This was my clue.www-data
's UID to 1000, so that the pre-existing permissions no longer apply.USER=www-data
, PUID=33
, PGID=33
would work as originally intended. Again, untested.@d7415 That makes sense, and it solved the storage issue, yes. Although there's still something funky going on.
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
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
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"
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).
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.
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):
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.
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.
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.
Ok, thanks for the update. I must have mistaken my problem with this one then, since I'm running on 4.5.3.
Based on @nagmat84's insight, I'm going to close this as the original issue should be fixed.
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.
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:
Output of the diagnostics [REQUIRED]
Troubleshooting and details
Docker configuration
Running on Docker on Ubuntu. docker-compose.yaml
/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
This repeates for every file. This is clearly a permissions issue. However, there are no issues on startup:
Startup logs
docker logs lychee
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
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
andchown -R www-data /var/www/html/Lychee/public/uploads/
but it didnt' seem to help or change it. Similar forchmod 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