Error 507 NoWriteAccessOnLogsExceptions
Opened this issue · 10 comments
Hi,
I use the docker-compose.yml provided in the code.
I don't have any problem to start my docker but when i try to connect i have this error 507
NoWriteAccessOnLogsExceptions
Could not write in the logs. Check that storage/logs/ and containing files have proper permissions.
Can you check that you have in your host:
root@vps:Lychee-docker/lychee ✗
▶ ls -ll
total 24
drwxr-xr-x 2 root root 4.0K Jan 18 15:20 conf
drwxrwsr-x 2 guest guest 4.0K May 22 2023 logs
drwxr-xr-x 6 999 docker 4.0K Jan 18 15:19 mysql
drwxrwsr-x 2 guest guest 4.0K Jan 19 03:06 sym
drwxrwsr-x 14 guest guest 4.0K Dec 27 13:29 uploadsi.e. make sure guest has write access on the lychee/logs in your host.
**** Create user and use PUID/PGID ****
User UID : 1000
User GID : 1000
**** Make sure Laravel's log exists ****
**** Set Permissions ****
**** Start cron daemon ****
External Permissions:
-rw-rw-r-- 1 1000 1000 0 2024-02-01 23:38 empty_file
-rw-rwSr-- 1 33 1000 0 2024-02-01 23:38 laravel.log
What GID/PID is necessary? So tired of this anti-root kick everyone is on, you can't run software the way you want anymore.
Edit: Even chmodding (for the sake of testing) 777 and chowning to the lowest (highest number, lowest permission*) IDs doesn't help.
Edit: Skipping permissions setting (because those cmds give whack permissions inside the container) and I can get through to Setting the environment but anything further results in I/O error for file '.env'. No idea where it's wanting to put such a file, I am not using any .env, those are useful only to head-enabled OS installations. My installation is Docker only using a compose.
What GID/PID is necessary?
That only matters if you're accessing the files from outside the container, or on a system that limits such things.
Skipping permissions setting (because those cmds give whack permissions inside the container)
If you mean the ones in entrypoint, those set the recommended permissions inside the container.
I am not using any .env
If you want Laravel to work, you're going to have to (or manually hack all of your settings into Lychee's files I suppose)
That only matters if you're accessing the files from outside the container, or on a system that limits such things.
Nah, I had to set everything to 33 (www-data). A clean folder created by docker on first start of container and it'd not do the permissions correctly.
If you mean the ones in entrypoint, those set the recommended permissions inside the container.
They break it (owner needed to stay 33 (www-data)). The built-in lychee is 1000 but www-data still couldn't read/write to it all.
If you want Laravel to work, you're going to have to (or manually hack all of your settings into Lychee's files I suppose)
I found out which .env it was talking about, container:/conf/.env. After setting PGID, PUID as I mentioned above (33) it all worked fine.
Now my only trouble is that Lychee doesn't seem to comprehend APP_DIR. I suspect an issue about APP_FORCE_HTTPS too but I can't confirm it until I can get Lychee to stop ignoring APP_DIR.
Also, DB_SOCKET is worthless. To anyone that finds it, you're welcome: DB_HOST=localhost;unix_socket=/var/run/YOUR_SQL_SOCKET.sock. Yes, the unix_socket in there is required or it just shits an error about files not being found, even if DB_SOCKET is used.
Ok, so.
- You do not appear to be doing anything similar to the original issue, so this is the wrong place for this discussion
- You appear to have an extremely unusual setup
They break it (owner needed to stay 33 (www-data)). The built-in lychee is 1000 but www-data still couldn't read/write to it all.
The entrypoint script adds www-data (in the container) to the lychee group so that it has access.
Also,
DB_SOCKETis worthless. To anyone that finds it, you're welcome:DB_HOST=localhost;unix_socket=/var/run/YOUR_SQL_SOCKET.sock. Yes, theunix_socketin there is required or it just shits an error about files not being found, even if DB_SOCKET is used.
This is a very unusual setup. You are free to use the Docker image as you wish, but if you do unusual things it's on you to figure out how to make them work, which you appear to have done.
- You appear to have an extremely unusual setup
This is a very unusual setup. You are free to use the Docker image as you wish, but if you do unusual things it's on you to figure out how to make them work, which you appear to have done.
Not at all, this is a rather common setup sharing a unix socket instead of opening up ports and networking (and their overhead and latencies coupling keeping track of container names for DHCP etc) between containers and software. Nothing unusual about that at all.
The entrypoint script adds www-data (in the container) to the lychee group so that it has access.
It doesn't. A clean setup, clean filesystem (allowing Docker to create it entirely of its own, so nothing of mine in the way at all) and it'll complain about not being able to access it. Accessing a shell console inside Lychee allows me to see it really wrecks the permissions on those, so I added SKIP_PERMISSIONS and fixed it within the shell of the container.
The bit about Lychee not respecting APP_DIR (or in short, the inability to use a subpath on a reverse-proxy which is a proper setup) doesn't belong here, it was just off the top of my head.
It doesn't
It does it at build time and again right here.
This seems to work for every user who isn't you.
It doesn't
It does it at build time and again right here.
This seems to work for every user who isn't you.
I noticed the Dockerfile and the entrypoint.sh, that's where I discovered the means to skip those permissions setting. I even tested it without any volume mounts and it still behaved that way, so I'm wondering if it is this NAS (a Qnap).
I'm wondering if it is this NAS (a Qnap).
That's very possible. They sometimes do weird things to permissions.
I'm wondering if it is this NAS (a Qnap).
That's very possible. They sometimes do weird things to permissions.
That is indeed why I mentioned it. It might also be why I need 33:33 on all of that.