Closed cearum closed 1 year ago
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
That's really strange. The code indeed looks correct: https://github.com/linuxserver/docker-babybuddy/blob/main/root/etc/s6-overlay/s6-rc.d/init-babybuddy-config/run#L4-L7 It first deletes the data folder, and then it creates the symlink correctly
And I spun up a new container and the symlink was correct and persisted through restarts:
root@f5ba4af17a0e:/app/www/public# ls -al data
lrwxrwxrwx 1 root root 12 Apr 13 14:43 data -> /config/data
Only thing I can think of is, perhaps in your instance, the rm -rf
of the folder is somehow failing, so the next command that creates the symlink creates it inside the existing folder. (or perhaps the symlink generation runs before rm is completed due to some weird io issue?)
Can you recreate the container with the env var S6_VERBOSITY=2
and post the full container log?
Also, are you running this in lxc, or with rootless docker or in portainer?
I'm running docker inside an unprivileged proxmox container (generated with https://tteck.github.io/Proxmox/).
# docker logs babybuddy
[mod-init] Version 3
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service init-migrations: starting
s6-rc: info: service init-envfile: starting
[migrations] started
s6-rc: info: service init-envfile successfully started
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
[migrations] 01-nginx-site-confs-default: skipped
s6-rc: info: service legacy-cont-init successfully started
[migrations] 02-default-location: skipped
[migrations] done
s6-rc: info: service init-migrations successfully started
s6-rc: info: service init-adduser: starting
───────────────────────────────────────
██╗ ███████╗██╗ ██████╗
██║ ██╔════╝██║██╔═══██╗
██║ ███████╗██║██║ ██║
██║ ╚════██║██║██║ ██║
███████╗███████║██║╚██████╔╝
╚══════╝╚══════╝╚═╝ ╚═════╝
Brought to you by linuxserver.io
───────────────────────────────────────
To support the app dev(s) visit:
BabyBuddy: https://github.com/sponsors/cdubz
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID: 1000
User GID: 1000
───────────────────────────────────────
s6-rc: info: service init-adduser successfully started
s6-rc: info: service init-os-end: starting
s6-rc: info: service init-os-end successfully started
s6-rc: info: service init-folders: starting
s6-rc: info: service init-folders successfully started
s6-rc: info: service init-samples: starting
s6-rc: info: service init-samples successfully started
s6-rc: info: service init-nginx: starting
s6-rc: info: service init-nginx successfully started
s6-rc: info: service init-php: starting
s6-rc: info: service init-php successfully started
s6-rc: info: service init-keygen: starting
using keys found in /config/keys
s6-rc: info: service init-keygen successfully started
s6-rc: info: service init-permissions: starting
s6-rc: info: service init-permissions successfully started
s6-rc: info: service init-nginx-end: starting
s6-rc: info: service init-nginx-end successfully started
s6-rc: info: service init-config: starting
s6-rc: info: service init-babybuddy-config: starting
s6-rc: info: service init-config successfully started
Operations to perform:
Apply all migrations: admin, auth, authtoken, axes, babybuddy, contenttypes, core, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying auth.0010_alter_group_name_max_length... OK
Applying auth.0011_update_proxy_permissions... OK
Applying auth.0012_alter_user_first_name_max_length... OK
Applying authtoken.0001_initial... OK
Applying authtoken.0002_auto_20160226_1747... OK
Applying authtoken.0003_tokenproxy... OK
Applying axes.0001_initial... OK
Applying axes.0002_auto_20151217_2044... OK
Applying axes.0003_auto_20160322_0929... OK
Applying axes.0004_auto_20181024_1538... OK
Applying axes.0005_remove_accessattempt_trusted... OK
Applying axes.0006_remove_accesslog_trusted... OK
Applying axes.0007_alter_accessattempt_unique_together... OK
Applying axes.0008_accessfailurelog... OK
Applying babybuddy.0001_initial... OK
Applying babybuddy.0002_add_settings... OK
Applying babybuddy.0003_add_refresh_help_text... OK
Applying babybuddy.0004_settings_language... OK
Applying babybuddy.0005_auto_20190502_1701... OK
Applying babybuddy.0006_auto_20190502_1744... OK
Applying babybuddy.0007_auto_20190607_1422... OK
Applying babybuddy.0008_auto_20200120_0622... OK
Applying babybuddy.0009_settings_timezone... OK
Applying babybuddy.0010_auto_20200609_0649... OK
Applying babybuddy.0011_auto_20200813_0238... OK
Applying babybuddy.0012_auto_20201024_1847... OK
Applying babybuddy.0013_auto_20210411_1241... OK
Applying babybuddy.0014_settings_hide_empty... OK
Applying babybuddy.0015_alter_settings_timezone... OK
Applying babybuddy.0016_alter_settings_timezone... OK
Applying babybuddy.0017_settings_hide_age... OK
Applying babybuddy.0018_auto_20211017_2136... OK
Applying babybuddy.0019_alter_settings_timezone... OK
Applying babybuddy.0020_update_language_en_to_en_us... OK
Applying babybuddy.0021_alter_settings_language... OK
Applying babybuddy.0022_alter_settings_language... OK
Applying babybuddy.0023_alter_settings_timezone... OK
Applying babybuddy.0025_auto_20221023_0821... OK
Applying babybuddy.0026_alter_settings_timezone... OK
Applying babybuddy.0027_remove_standard_group... OK
Applying core.0001_initial... OK
Applying core.0002_auto_20171028_1257... OK
Applying core.0003_weight... OK
Applying core.0004_child_picture... OK
Applying core.0005_auto_20190416_2048... OK
Applying core.0006_auto_20190502_1701... OK
Applying core.0007_temperature... OK
Applying core.0008_auto_20190607_1422... OK
Applying core.0009_diaperchange_amount... OK
Applying core.0010_timer_child... OK
Applying core.0011_auto_20200214_1939... OK
Applying core.0012_auto_20200813_0238... OK
Applying core.0013_auto_20210415_0528... OK
Applying core.0014_alter_child_slug... OK
Applying core.0015_add_nap_field_for_sleep... OK
Applying core.0016_alter_sleep_napping... OK
Applying core.0017_alter_child_last_name... OK
Applying core.0018_bmi_headcircumference_height... OK
Applying core.0019_tag_tagged_note_tags... OK
Applying core.0020_bmi_tags_diaperchange_tags_feeding_tags_and_more... OK
Applying core.0021_pumping... OK
Applying core.0022_alter_default_date_and_time... OK
Applying core.0023_alter_tag_options_alter_bmi_tags_and_more... OK
Applying core.0024_alter_tag_slug... OK
Applying core.0025_pumping_tags... OK
Applying sessions.0001_initial... OK
s6-rc: info: service init-babybuddy-config successfully started
s6-rc: info: service init-config-end: starting
s6-rc: info: service init-config-end successfully started
s6-rc: info: service init-version-checks: starting
s6-rc: info: service init-version-checks successfully started
s6-rc: info: service init-mods: starting
s6-rc: info: service init-mods successfully started
s6-rc: info: service init-mods-package-install: starting
s6-rc: info: service init-mods-package-install successfully started
s6-rc: info: service init-mods-end: starting
s6-rc: info: service init-mods-end successfully started
s6-rc: info: service init-custom-files: starting
[custom-init] No custom files found, skipping...
s6-rc: info: service init-custom-files successfully started
s6-rc: info: service init-services: starting
s6-rc: info: service init-services successfully started
s6-rc: info: service svc-nginx: starting
s6-rc: info: service svc-cron: starting
s6-rc: info: service svc-babybuddy: starting
s6-rc: info: service svc-nginx successfully started
s6-rc: info: service svc-cron successfully started
[2023-04-13 10:52:06 -0400] [220] [INFO] Starting gunicorn 20.1.0
[2023-04-13 10:52:06 -0400] [220] [INFO] Listening at: http://127.0.0.1:3000 (220)
[2023-04-13 10:52:06 -0400] [220] [INFO] Using worker: gthread
[2023-04-13 10:52:06 -0400] [232] [INFO] Booting worker with pid: 232
[2023-04-13 10:52:06 -0400] [233] [INFO] Booting worker with pid: 233
s6-rc: info: service svc-babybuddy successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
s6-rc: info: service ci-service-check: starting
[ls.io-init] done.
s6-rc: info: service ci-service-check successfully started
Bingo. Unprivileged lxc is most definitely your issue.
Fwiw, lately we've been getting a ton of weird issue reports from users with unprivileged lxc containers. It causes all sorts of unexpected issues that are hard to diagnose.
A team member just set up a privileged lxc container and did some tests inside. All seemed well. So if you really need to use lxc, at least make sure it's privileged.
Docker service by default expects to have full access to the system and the kernel and all resources. But if you put docker inside another container, let alone an unprivileged one, docker behaves in all sorts of weird ways because it now lacks authorization to do certain things it expects to be able to do.
Also, even the proxmox devs are recommending against running docker in lxc (let alone an unprivileged one): https://forum.proxmox.com/threads/podman-in-lxc-what-do-overlay-not-support-file-handles-and-conflicting-options-userxattr-metacopy-mean.121825/#post-529565
I'll try to create a full VM just for docker stuff and try again. For what it's worth I changed it to a privileged container (not show how well changing it works) and it was the same result.
Thank you for the assistance. I've taken heed of the lxc and docker, and I will move my docker containers to my vm. This was the first one to have issues, but I'm sure it was a matter of time before one did.
In the meantime, can you post the output of lxc config show --expanded <container name>
on your host?
Our team member's lxc is on a debian bullseye VM on esxi and with privilege he can't reproduce any of these issues. But we don't have proxmox set up to seewhat kind of differences there may be.
We must have posted about the same time. I got it working in a VM. I had actually removed the lxc as I moved all of my data/configs to the vm. However, I made a new lxc that starts as privileged and got it to work. I did need to enable either nesting or fuse in the options to get it to work though.
Thanks so much for that info. We'll share with others having similar issues.
Is there an existing issue for this?
Current Behavior
When checking inside the container I find that the symbolic link is being created at /app/www/public/data/data
Because the symoblic link isn't in the right place the permissions setting in the 's6-rc.d/init-babybuddy-config/run' isn't being performed on the folder and the database isn't writable.
When the permissions were changed within the container then login worked. When container is restarted (with docker-compose) it no longer worked again.
Expected Behavior
The symbolic link should be at /app/www/public/data so that the database is writable.
Steps To Reproduce
Environment
CPU architecture
x86-64
Docker creation