Open nath2125 opened 1 year ago
Hi! This looks like an internal server error, are you sure there's nothing in the logs? You can also set DJANGO_DEBUG
and try again, it will show you the error on the browser
Hi! This looks like an internal server error, are you sure there's nothing in the logs? You can also set
DJANGO_DEBUG
and try again, it will show you the error on the browser
Il post the logs im getting for the wger_server below:
yarn install v1.22.19
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
[4/5] Linking dependencies...
[5/5] Building fresh packages...
Done in 10.82s.
yarn run v1.22.19
$ sass wger/core/static/scss/main.scss:wger/core/static/yarn/bootstrap-compiled.css
Done in 2.80s.
Running in production mode, running collectstatic now
15780 static files copied to '/home/wger/static'.
Performing database migrations
Operations to perform:
Apply all migrations: actstream, auth, authtoken, axes, config, contenttypes, core, easy_thumbnails, exercises, gallery, gym, mailer, manager, measurements, nutrition, sessions, sites, weight
Running migrations:
No migrations to apply.
Your models in app(s): 'config', 'core' have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
Set site URL to http://localhost
Using gunicorn...
[2023-02-18 13:10:30 +0000] [79] [INFO] Starting gunicorn 20.1.0
[2023-02-18 13:10:30 +0000] [79] [INFO] Listening at: http://0.0.0.0:8000 (79)
[2023-02-18 13:10:30 +0000] [79] [INFO] Using worker: sync
[2023-02-18 13:10:30 +0000] [80] [INFO] Booting worker with pid: 80
This is the db
PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-02-12 12:58:50.453 UTC [1] LOG: starting PostgreSQL 12.14 on x86_64-pc-linux-musl, compiled by gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924, 64-bit
2023-02-12 12:58:50.453 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2023-02-12 12:58:50.453 UTC [1] LOG: listening on IPv6 address "::", port 5432
2023-02-12 12:58:50.460 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-02-12 12:58:50.485 UTC [22] LOG: database system was shut down at 2023-02-12 12:56:29 UTC
2023-02-12 12:58:50.492 UTC [1] LOG: database system is ready to accept connections
2023-02-12 13:01:36.009 UTC [1] LOG: received fast shutdown request
2023-02-12 13:01:36.014 UTC [1] LOG: aborting any active transactions
2023-02-12 13:01:36.033 UTC [1] LOG: background worker "logical replication launcher" (PID 28) exited with exit code 1
2023-02-12 13:01:36.033 UTC [23] LOG: shutting down
2023-02-12 13:01:36.112 UTC [1] LOG: database system is shut down
PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-02-12 13:08:02.670 UTC [1] LOG: starting PostgreSQL 12.14 on x86_64-pc-linux-musl, compiled by gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924, 64-bit
2023-02-12 13:08:02.670 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2023-02-12 13:08:02.670 UTC [1] LOG: listening on IPv6 address "::", port 5432
2023-02-12 13:08:02.677 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-02-12 13:08:02.786 UTC [22] LOG: database system was shut down at 2023-02-12 13:01:36 UTC
2023-02-12 13:08:02.804 UTC [1] LOG: database system is ready to accept connections
wger_cache
1:C 12 Feb 2023 12:58:50.374 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 12 Feb 2023 12:58:50.374 # Redis version=7.0.8, bits=64, commit=00000000, modified=0, pid=1, just started
1:C 12 Feb 2023 12:58:50.374 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
1:M 12 Feb 2023 12:58:50.375 * monotonic clock: POSIX clock_gettime
1:M 12 Feb 2023 12:58:50.376 * Running mode=standalone, port=6379.
1:M 12 Feb 2023 12:58:50.376 # Server initialized
1:M 12 Feb 2023 12:58:50.377 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
1:M 12 Feb 2023 12:58:50.377 * Ready to accept connections
1:signal-handler (1676206895) Received SIGTERM scheduling shutdown...
1:M 12 Feb 2023 13:01:36.042 # User requested shutdown...
1:M 12 Feb 2023 13:01:36.042 * Saving the final RDB snapshot before exiting.
1:M 12 Feb 2023 13:01:36.049 * DB saved on disk
1:M 12 Feb 2023 13:01:36.049 # Redis is now ready to exit, bye bye...
1:C 12 Feb 2023 13:08:00.430 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 12 Feb 2023 13:08:00.433 # Redis version=7.0.8, bits=64, commit=00000000, modified=0, pid=1, just started
1:C 12 Feb 2023 13:08:00.434 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
1:M 12 Feb 2023 13:08:00.434 * monotonic clock: POSIX clock_gettime
1:M 12 Feb 2023 13:08:00.437 * Running mode=standalone, port=6379.
1:M 12 Feb 2023 13:08:00.437 # Server initialized
1:M 12 Feb 2023 13:08:00.437 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
1:M 12 Feb 2023 13:08:00.438 * Loading RDB produced by version 7.0.8
1:M 12 Feb 2023 13:08:00.438 * RDB age 384 seconds
1:M 12 Feb 2023 13:08:00.438 * RDB memory usage when created 0.91 Mb
1:M 12 Feb 2023 13:08:00.438 * Done loading RDB, keys loaded: 0, keys expired: 0.
1:M 12 Feb 2023 13:08:00.438 * DB loaded from disk: 0.000 seconds
1:M 12 Feb 2023 13:08:00.438 * Ready to accept connections
1:M 12 Feb 2023 14:08:01.078 * 1 changes in 3600 seconds. Saving...
1:M 12 Feb 2023 14:08:01.078 * Background saving started by pid 2519
2519:C 12 Feb 2023 14:08:01.093 * DB saved on disk
2519:C 12 Feb 2023 14:08:01.094 * Fork CoW for RDB: current 0 MB, peak 0 MB, average 0 MB
1:M 12 Feb 2023 14:08:01.179 * Background saving terminated with success
nginix:
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: /etc/nginx/conf.d/default.conf is not a file or does not exist
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2023/02/12 13:32:23 [notice] 1#1: using the "epoll" event method
2023/02/12 13:32:23 [notice] 1#1: nginx/1.22.1
2023/02/12 13:32:23 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6)
2023/02/12 13:32:23 [notice] 1#1: OS: Linux 5.10.0-21-amd64
2023/02/12 13:32:23 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2023/02/12 13:32:23 [notice] 1#1: start worker processes
2023/02/12 13:32:23 [notice] 1#1: start worker process 19
2023/02/12 13:32:23 [notice] 1#1: start worker process 20
2023/02/12 13:52:34 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2023/02/12 13:52:34 [notice] 20#20: gracefully shutting down
2023/02/12 13:52:34 [notice] 19#19: gracefully shutting down
2023/02/12 13:52:34 [notice] 20#20: exiting
2023/02/12 13:52:34 [notice] 19#19: exiting
2023/02/12 13:52:34 [notice] 19#19: exit
2023/02/12 13:52:34 [notice] 20#20: exit
2023/02/12 13:52:34 [notice] 1#1: signal 17 (SIGCHLD) received from 19
2023/02/12 13:52:34 [notice] 1#1: worker process 19 exited with code 0
2023/02/12 13:52:34 [notice] 1#1: worker process 20 exited with code 0
2023/02/12 13:52:34 [notice] 1#1: exit
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: /etc/nginx/conf.d/default.conf differs from the packaged version
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2023/02/12 13:52:35 [notice] 1#1: using the "epoll" event method
2023/02/12 13:52:35 [notice] 1#1: nginx/1.22.1
2023/02/12 13:52:35 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6)
2023/02/12 13:52:35 [notice] 1#1: OS: Linux 5.10.0-21-amd64
2023/02/12 13:52:35 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2023/02/12 13:52:35 [notice] 1#1: start worker processes
2023/02/12 13:52:35 [notice] 1#1: start worker process 28
2023/02/12 13:52:35 [notice] 1#1: start worker process 29
Everything looks alright. specially the wger_server one where the error should be logged. Can you try changing the debug setting?
Everything looks alright. specially the wger_server one where the error should be logged. Can you try changing the debug setting?
I've set DJANGO_DEBUG to True and il update the stack and see what i get
content = loader.render_to_string(template_name, context, request, using=using)
File "/usr/local/lib/python3.10/dist-packages/django/template/loader.py", line 62, in render_to_string
return template.render(context, request)
File "/usr/local/lib/python3.10/dist-packages/django/template/backends/django.py", line 62, in render
return self.template.render(context)
File "/usr/local/lib/python3.10/dist-packages/django/template/base.py", line 173, in render
with context.bind_template(self):
File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
return next(self.gen)
File "/usr/local/lib/python3.10/dist-packages/django/template/context.py", line 254, in bind_template
updates.update(processor(self.request))
File "/home/wger/src/wger/utils/context_processor.py", line 28, in processor
language = load_language()
File "/home/wger/src/wger/utils/language.py", line 49, in load_language
language = Language.objects.get(short_name=ENGLISH_SHORT_NAME)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/manager.py", line 85, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/query.py", line 650, in get
raise self.model.DoesNotExist(
wger.core.models.language.Language.DoesNotExist: Language matching query does not exist.
Internal Server Error: /en/software/features
Traceback (most recent call last):
File "/home/wger/src/wger/utils/language.py", line 47, in load_language
language = Language.objects.get(short_name=used_language)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/manager.py", line 85, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/query.py", line 650, in get
raise self.model.DoesNotExist(
wger.core.models.language.Language.DoesNotExist: Language matching query does not exist.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/django/core/handlers/exception.py", line 55, in inner
response = get_response(request)
File "/usr/local/lib/python3.10/dist-packages/django/core/handlers/base.py", line 197, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/wger/src/wger/software/views.py", line 37, in features
return render(request, 'features.html', context)
File "/usr/local/lib/python3.10/dist-packages/django/shortcuts.py", line 24, in render
content = loader.render_to_string(template_name, context, request, using=using)
File "/usr/local/lib/python3.10/dist-packages/django/template/loader.py", line 62, in render_to_string
return template.render(context, request)
File "/usr/local/lib/python3.10/dist-packages/django/template/backends/django.py", line 62, in render
return self.template.render(context)
File "/usr/local/lib/python3.10/dist-packages/django/template/base.py", line 173, in render
with context.bind_template(self):
File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
return next(self.gen)
File "/usr/local/lib/python3.10/dist-packages/django/template/context.py", line 254, in bind_template
updates.update(processor(self.request))
File "/home/wger/src/wger/utils/context_processor.py", line 28, in processor
language = load_language()
File "/home/wger/src/wger/utils/language.py", line 49, in load_language
language = Language.objects.get(short_name=ENGLISH_SHORT_NAME)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/manager.py", line 85, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/query.py", line 650, in get
raise self.model.DoesNotExist(
wger.core.models.language.Language.DoesNotExist: Language matching query does not exist.
Internal Server Error: /en/software/features
Traceback (most recent call last):
File "/home/wger/src/wger/utils/language.py", line 47, in load_language
language = Language.objects.get(short_name=used_language)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/manager.py", line 85, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/query.py", line 650, in get
raise self.model.DoesNotExist(
wger.core.models.language.Language.DoesNotExist: Language matching query does not exist.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/django/core/handlers/exception.py", line 55, in inner
response = get_response(request)
File "/usr/local/lib/python3.10/dist-packages/django/core/handlers/base.py", line 197, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/wger/src/wger/software/views.py", line 37, in features
return render(request, 'features.html', context)
File "/usr/local/lib/python3.10/dist-packages/django/shortcuts.py", line 24, in render
content = loader.render_to_string(template_name, context, request, using=using)
File "/usr/local/lib/python3.10/dist-packages/django/template/loader.py", line 62, in render_to_string
return template.render(context, request)
File "/usr/local/lib/python3.10/dist-packages/django/template/backends/django.py", line 62, in render
return self.template.render(context)
File "/usr/local/lib/python3.10/dist-packages/django/template/base.py", line 173, in render
with context.bind_template(self):
File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
return next(self.gen)
File "/usr/local/lib/python3.10/dist-packages/django/template/context.py", line 254, in bind_template
updates.update(processor(self.request))
File "/home/wger/src/wger/utils/context_processor.py", line 28, in processor
language = load_language()
File "/home/wger/src/wger/utils/language.py", line 49, in load_language
language = Language.objects.get(short_name=ENGLISH_SHORT_NAME)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/manager.py", line 85, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/django/db/models/query.py", line 650, in get
raise self.model.DoesNotExist(
wger.core.models.language.Language.DoesNotExist: Language matching query does not exist.
I get this in the logs now for the wger_Server
ok, at least we have something now. It seems something went wrong when initialising the database. The easiest would be to drop the db volume and start everything again. If everything goes right, you should see a couple of messages like "installed x objects from y fixtures"
which one does do i need to get rid of the db volume? is that the volume under "postgres"?
I just changed my dockercompose to these volumes still coming up with the same issues I believe since i turned the debug back to false and comes up with same issue photo as above.
#
# Please consult the `Deployment` section in the readme if you want to deploy
# this. You need to keep this nginx service, even if you have your own, otherwise
# the static files will not be served correctly!
#
services:
web:
image: wger/server:latest
container_name: wger_server
depends_on:
db:
condition: service_healthy
cache:
condition: service_healthy
env_file:
- stack.env
volumes:
- ./wger/static:/home/wger/static
- ./wger/media:/home/wger/media
# For development, mount your local git checkout
# - type: bind
# source: /path/to/wger/sourcecode
# target: /home/wger/src/
ports:
- "8005:8000"
healthcheck:
test: wget --no-verbose --tries=1 --spider http://localhost:8000
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
nginx:
image: nginx:stable
container_name: wger_nginx
env_file:
- stack.env
depends_on:
- web
volumes:
- ./config/nginx:/etc/nginx/conf.d/
- static:/wger/static:ro
- media:/wger/media:ro
ports:
- "80:80"
healthcheck:
test: service nginx status
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
db:
image: postgres:12-alpine
container_name: wger_db
env_file:
- stack.env
environment:
- POSTGRES_USER=wger
- POSTGRES_PASSWORD=wger
- POSTGRES_DB=wger
volumes:
- ./postgres-data:/var/lib/postgresql/data/
expose:
- 5432
healthcheck:
test: pg_isready -U wger
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
cache:
image: redis
env_file:
- stack.env
container_name: wger_cache
expose:
- 6379
healthcheck:
test: redis-cli ping
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
volumes:
postgres-data:
static:
media:
networks:
default:
name: wger_network
yes, just do a docker volume rm docker_postgres-data
(if it has another prefix, do a docker volume ls
to list all available ones. If everything works correctly the server logs should look like this
wger_server | *** Database does not exist, creating one now
wger_server | Operations to perform:
wger_server | Apply all migrations: actstream, auth, authtoken, axes, config, contenttypes, core, easy_thumbnails, exercises, gallery, gym, mailer, manager, measurements, nutrition, sessions, sites, weight
wger_server | Running migrations:
wger_server | Applying contenttypes.0001_initial... OK
wger_server | Applying auth.0001_initial... OK
wger_server | Applying actstream.0001_initial... OK
wger_server | Applying actstream.0002_remove_action_data... OK
wger_server | Applying actstream.0003_add_follow_flag... OK
wger_server | Applying contenttypes.0002_remove_content_type_name... OK
wger_server | Applying auth.0002_alter_permission_name_max_length... OK
wger_server | Applying auth.0003_alter_user_email_max_length... OK
wger_server | Applying auth.0004_alter_user_username_opts... OK
wger_server | Applying auth.0005_alter_user_last_login_null... OK
[...]
wger_server | Installed 1 object(s) from 1 fixture(s)
wger_server | Installed 24 object(s) from 1 fixture(s)
wger_server | Installed 6 object(s) from 1 fixture(s)
wger_server | Installed 3 object(s) from 1 fixture(s)
wger_server | Installed 5 object(s) from 1 fixture(s)
wger_server | Installed 7 object(s) from 1 fixture(s)
wger_server | Installed 6 object(s) from 1 fixture(s)
wger_server | Installed 6 object(s) from 1 fixture(s)
wger_server | Installed 1 object(s) from 1 fixture(s)
wger_server | Installed 10 object(s) from 1 fixture(s)
wger_server | Installed 15 object(s) from 1 fixture(s)
wger_server | Installed 8 object(s) from 1 fixture(s)
wger_server | Installed 416 object(s) from 1 fixture(s)
wger_server | Installed 1256 object(s) from 1 fixture(s)
wger_server | Installed 1 object(s) from 1 fixture(s)
wger_server | Installed 1 object(s) from 1 fixture(s)
wger_server | Installed 1 object(s) from 1 fixture(s)
wger_server | *** Password for user admin was reset to 'adminadmin'
wger_server | Installed 3 object(s) from 1 fixture(s)
wger_server | yarn install v1.22.19
wger_server | [1/5] Validating package.json...
wger_server | [2/5] Resolving packages...
wger_server | [3/5] Fetching packages...
^[[Bwger_server | [4/5] Linking dependencies...
wger_server | [5/5] Building fresh packages...
wger_server | Done in 4.84s.
wger_server | yarn run v1.22.19
wger_server | $ sass wger/core/static/scss/main.scss:wger/core/static/yarn/bootstrap-compiled.css
wger_server | Done in 0.97s.
wger_server | Running in production mode, running collectstatic now
wger_server |
wger_server | 5726 static files copied to '/home/wger/static', 10054 unmodified.
Alright i went back to my old compose, and deleted the volumes like you said seems to be working fine now. Everything appears in clear text now. Is there an actual coloured and layed out webgui once your past the registering and stuff like that?
ok great. Would have been nice to know what happened the first time, but oh well. What do you mean with clear text?
wait I see it now in the screenshot, you should access everything over nginx's port, 80 by default, django doesn't server any static files itself
At the moment its all clear text, not many prompts or images. Didn't know if this is how its ment to look
just open http://localhost, not localhost:8005
Any way to change it from using localhost with no port designation to a port? since i run multiple containers and portainer over that ip address?
yeah, you can just change the port nginx exposes, so 8080:80 or whatever you need
Easy thank you! For all your help. Interms of question of what is the origin of the problem. I can say from memory i was having a lot if issues setting it up as a stack with compose in the portainer and kept deploying over the same volumes so I would have to say probably an issue with my setting up which caused this and maybe it broke because of rewriting? but yea sorry i couldnt give u a full summary.
Glad it works! And now that you mention it, somebody was also having weird problems with the db and it turns out that if you don't start it directly with docker compose but let it be managed by something else, the image starting order is not respected so the server container starts before the database is ready and can't complete the init process. Don't know if they were using portainer as well though
getting this now after registering an account through the gui with my email. Is this because it cant send a verification email to my email address? or another issue?
Let me know your take on this, as im not sure what this is suggesting.
take a look at the "read this if you are using https" in the readme (it still applies even if you don't use encryption. Basically you need to whitelist the domain or ip/port you are using
Experiencing same symptoms with non-compose installation.
@rolandgeider is static dir recreated on server restart as claimed in readme? As I can't use docker compose I'm using regular bind mounts, and static dir is never populated:
┌─[/mnt/user/appdata/wger]
└──╼ $ tree -a
.
|-- media
`-- static
2 directories, 0 files
Docker mounts:
/home/wger/media -> /mnt/user/appdata/wger/media
/home/wger/static -> /mnt/user/appdata/wger/static
@laur89 from other people, I know that mounting volumes makes some problems (probably some user UIDs don't match), but other than that, it should work the same
To be clear, ~/static dir should not be empty, correct?
Note I doubt it's permissions issue, as listing the home dir from within the container looks OK to me:
wger@abf427a79b77:~$ ls -lAtr /home/wger/
total 20
-rw-r--r-- 1 wger wger 807 Jun 13 09:47 .profile
-rw-r--r-- 1 wger wger 3771 Jun 13 09:47 .bashrc
-rw-r--r-- 1 wger wger 220 Jun 13 09:47 .bash_logout
-rwxr-xr-x 1 root root 1729 Jun 13 10:07 entrypoint.sh
drwxr-xr-x 1 wger wger 586 Jun 13 10:09 src
drwx------ 1 wger wger 12 Jun 13 10:09 .local
drwxr-xr-x 1 wger wger 0 Jun 13 10:09 db
drwxr-xr-x 1 wger wger 0 Jun 13 10:09 beat
drwxrwxrwx 1 wger users 6 Jun 13 17:22 media
drwxrwxrwx 1 wger users 6 Jun 13 17:22 static
drwxr-xr-x 1 wger wger 8 Jun 13 20:16 .cache
drwxr-xr-x 1 wger wger 6 Jun 13 20:16 .yarn
-rw------- 1 wger wger 35 Jun 13 20:16 .bash_history
Creating files manually from within container works:
wger@abf427a79b77:~/src$ touch /home/wger/static/new
wger@abf427a79b77:~/src$ echo $?
0
Yet the static/ dir remains empty. Container startup checks show no issues:
Performing system checks...
System check identified no issues (0 silenced).
June 13, 2023 - 20:07:32
Okay, got it working. Problem is the static/ dir is not initialised if DJANGO_DEBUG = True
. I'd argue this is problematic.
Bit in the same vein - had earlier setup problems because email port was required although the email option was not toggled. That caused the application startup to fail. And this in turn, I believe, caused a dirty db init, requiring the table to be re-created prior to server restart (having solved all the configuration problems beforehand). Would you accept a FR ticket for these problems?
Just doing a fresh install and came across this same problem.
Interestingly... my instance only works if DJANGO_DEBUG = True
As soon as i set it to False the sever starts up but assets just get 404
This is showing up when I go to my WebGUI
Not really seeing any errors as such in the logs just this when i try to access to UI
Copy of my docker-compose I used.