after each restart, all files are recreated #2
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Griefed/docker-SUI#2
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What is the current behavior?
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
What is the expected behavior?
What is the motivation / use case for changing the behavior?
Please tell us about your environment:
docker version && docker-compose versionWhat's the configuration you're starting the container with? Docker-compose?
How did you map the volume for the container? If the files are always recreated whenever you restart the container, it may be due to a incorrect mapping of the volume where the data is stored to.
the data is mapped, I can edit it on the host machine - everything is ok.
But as soon as I do restart or down of the container. All data in volume is overwritten with new files
my docker-compose (default)
version: "2"
services:
sui:
image: griefed/sui:latest
container_name: sui
restart: unless-stopped
environment:
- TZ=Europe/Minsk
- PUID=1005
- PROTOCOL=https
- PGID=100
- DOMAIN=my domain
volumes:
-./config:/config
ports:
- 443:443/tcp # https
- 80:80/tcp # http
WARNING: The Docker Engine you're using is running in swarm mode.
Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.
To deploy your application across the swarm, use
docker stack deploy.Creating sui ... done
Attaching to sui
sui | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
sui | [s6-init] ensuring user provided files have correct perms...exited 0.
sui | [fix-attrs.d] applying ownership & permissions fixes...
sui | [fix-attrs.d] done.
sui | [cont-init.d] executing container initialization scripts...
sui | [cont-init.d] 01-envfile: executing...
sui | [cont-init.d] 01-envfile: exited 0.
sui | [cont-init.d] 10-adduser: executing...
sui |
sui | -------------------------------------
sui | _ ()
sui | | | ___ _ __
sui | | | / | | | / \
sui | | | _ \ | | | () |
sui | || |/ || __/
sui |
sui |
sui | Brought to you by linuxserver.io
sui | -------------------------------------
sui |
sui | To support LSIO projects visit:
sui | https://www.linuxserver.io/donate/
sui | -------------------------------------
sui | GID/UID
sui | -------------------------------------
sui |
sui | User uid: 1005
sui | User gid: 100
sui | -------------------------------------
sui |
sui | [cont-init.d] 10-adduser: exited 0.
sui | [cont-init.d] 20-config: executing...
sui | [cont-init.d] 20-config: exited 0.
sui | [cont-init.d] 30-install: executing...
sui | **** Installing SUI ****
sui | rm: cannot remove '/config/www/assets': Is a directory
sui | Cloning into '/tmp/sui'...
sui | [cont-init.d] 30-install: exited 0.
sui | [cont-init.d] 30-keygen: executing...
sui | using keys found in /config/keys
sui | [cont-init.d] 30-keygen: exited 0.
sui | [cont-init.d] 40-config: executing...
sui | [cont-init.d] 40-config: exited 0.
sui | [cont-init.d] 99-custom-files: executing...
sui | [custom-init] no custom files found exiting...
sui | [cont-init.d] 99-custom-files: exited 0.
sui | [cont-init.d] done.
sui | [services.d] starting services
sui | [services.d] done.
Description: Debian GNU/Linux 10 (buster)
Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux
Docker version 20.10.6, build 370c289
docker-compose version 1.25.4, build 8d51620a
Thanks for providing this additional information. I'll look into it and try to figure out why this is happening to you. I have a suspicion that this behaviour is due to you running in Swarm Mode, but I am not quite sure, because I not fully familiar with Swarm Mode. I'll see what I can do and get back to you. 🙂
Yes, this host is added to swarm, but I'm not running through swarm. Therefore, there is this warning. At the moment, I am deploying it locally on my laptop to exclude this assumption.
Thank you also for your prompt reply. It is very pleasant and important.
I see in this repository you have it in cont-init.d / 40-config
if [! -a /config/www/apps.json];
and here
https://github.com/Griefed/docker-App-Collection/blob/main/root/etc/cont-init.d/40-config
if [ ! -f /config/www/apps.json ];
this is not critical?
I've tried reproducing your issue (albeit not in a swarm environment, as I don't have one) and am having at least similar log output:
The troublesome lines are
as they should only be displayed if the
sui.lockfile could not be found within/config/www/inside the container. Thing is, said file is there but the container can't seem to find it, which is most troubling to say the least.root/etc/cont-init.d/30-installchecks for existence ofsui.lockvia [ ! -a /config/www/sui.lock ]. That means the code inside that block should only be executed if said file does not exist, yet it enters the block even if it exists.That would explain why your files vanish everytime you restart the container. The container wants to re-install the software even though it is not supposed to.
lolwhoops.
Sorry for closing your issue. It appears pull requests can close issues all by themselves. I did not know that.
Anyway.
I have implemented a change which appears to have fixed the issue you reported.
Looks good!
Try pulling the latest image again, or 1.0.2, and see whether this fixed your issue. 😊
Alas, everything also rewrites apps.json
can change here?
https://github.com/Griefed/docker-SUI/blob/lsiobase/nginx/root/etc/cont-init.d/40-config
! -a on ! -f
p.s: and so YES!
the current error is gone
"rm: cannot remove '/config/www/assets': Is a directory"
Oh, so the error regarding
rm: cannot remove '/config/www/assets': Is a directoryis gone, butapps.json,links.json&index.htmlare still being replaced with their defaults?Alrighty, I'll take another look. I have a suspicion where the error lies already.
Yes, that is right
Right, please try again with latest or 1.0.3 as I've changed the checks for the affected three files and added some log output with
github.com/Griefed/docker-SUI@33349382ca!!!!Everything works now 1.0.3 !!!!!
Cool
Thank you
For the support.
Will put things in order and beauty at home
Awesome! Glad to hear that it works now! Sorry for the trouble you had to go through. 😅 But thank you for reporting this issue to me.
Have a good one and have fun. :)
I'll close this issue now.