Regression: 502 with 0.20.4 (Docker & NPM) #2024

Closed
opened 2023-03-11 00:33:23 +00:00 by lluni · 20 comments

Description

I faced a regression when updating the frontend 0.20.3 -> 0.20.4. Now, Vikunja only gives a 502 Bad Gateway and the following lines are logged in the frontend container every 30s:

/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/20-envsubst-on-templates.sh
20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/50-injector.sh
info: API URL is /api/v1
info: Sentry enabled: false
info: started at 2023-03-11T00:05:52+00:00
/docker-entrypoint.sh: Launching /docker-entrypoint.d/60-ipv6-disable.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2023/03/11 00:05:52 [emerg] 1#1: bind() to 0.0.0.0:80 failed (13: Permission denied)
nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)

The deployment of the updated api container (0.20.2 -> 0.20.3) worked without problems.

The following setup works without problems with frontend/api versions 0.20.3/0.20.2 and 0.20.3/0.20.3 but not with 0.20.4/0.20.3:

NGINX Proxy Manager:

(shortened info, setup was done with only the NPM web-interface, i.e. no manual config editing)

Proxy Host

tasks.example.com
http://vikunja_frontend:80

Custom Locations

location /
http://vikunja_frontend:80

location ~* ^/(api|dav|.well-known)/
http://vikunja_api:3456
client_max_body_size 20M;

SSL

A valid SSL certificate for tasks.example.com is selected.
Only enabled option is HTTP/2 Support.

Advanced
gzip  on;
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml;

docker-compose.yml

version: '3'

services:
  db:
    image: mariadb:10
    container_name: vikunja_db
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    environment:
      MYSQL_ROOT_PASSWORD: [redacted]
      MYSQL_USER: vikunja
      MYSQL_PASSWORD: [redacted]
      MYSQL_DATABASE: vikunja
    volumes:
      - ./db:/var/lib/mysql
    networks:
      - vikunja
    restart: unless-stopped
  api:
    image: vikunja/api
    container_name: vikunja_api
    environment:
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_PASSWORD: [redacted]
      VIKUNJA_DATABASE_TYPE: mysql
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_DATABASE: vikunja
      VIKUNJA_SERVICE_JWTSECRET: [redacted]
      VIKUNJA_SERVICE_FRONTENDURL: https://tasks.example.com
      # env vars
      VIKUNJA_SERVICE_ENABLEREGISTRATION: "false"
    volumes:
      - ./files:/app/vikunja/files
    networks:
      - vikunja
      - npm_bridge
    depends_on:
      - db
    restart: unless-stopped
  frontend:
    image: vikunja/frontend:0.20.3
    container_name: vikunja_frontend
    networks:
      - vikunja
      - npm_bridge
    restart: unless-stopped
networks:
  vikunja:
  npm_bridge:
    external: true

Vikunja Frontend Version

0.20.3

Vikunja API Version

0.20.3

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

### Description I faced a regression when updating the frontend 0.20.3 -> 0.20.4. Now, Vikunja only gives a 502 Bad Gateway and the following lines are logged in the frontend container every 30s: ``` /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/20-envsubst-on-templates.sh 20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/50-injector.sh info: API URL is /api/v1 info: Sentry enabled: false info: started at 2023-03-11T00:05:52+00:00 /docker-entrypoint.sh: Launching /docker-entrypoint.d/60-ipv6-disable.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2023/03/11 00:05:52 [emerg] 1#1: bind() to 0.0.0.0:80 failed (13: Permission denied) nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ``` The deployment of the updated api container (0.20.2 -> 0.20.3) worked without problems. The following setup works without problems with frontend/api versions 0.20.3/0.20.2 and 0.20.3/0.20.3 but *not* with 0.20.4/0.20.3: #### NGINX Proxy Manager: (shortened info, setup was done with only the NPM web-interface, i.e. no manual config editing) ##### Proxy Host tasks.example.com http://vikunja_frontend:80 ##### Custom Locations location / http://vikunja_frontend:80 location ~* ^/(api|dav|\.well-known)/ http://vikunja_api:3456 client_max_body_size 20M; ##### SSL A valid SSL certificate for tasks.example.com is selected. Only enabled option is `HTTP/2 Support`. ##### Advanced ``` gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_min_length 256; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml; ``` #### docker-compose.yml ``` version: '3' services: db: image: mariadb:10 container_name: vikunja_db command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci environment: MYSQL_ROOT_PASSWORD: [redacted] MYSQL_USER: vikunja MYSQL_PASSWORD: [redacted] MYSQL_DATABASE: vikunja volumes: - ./db:/var/lib/mysql networks: - vikunja restart: unless-stopped api: image: vikunja/api container_name: vikunja_api environment: VIKUNJA_DATABASE_HOST: db VIKUNJA_DATABASE_PASSWORD: [redacted] VIKUNJA_DATABASE_TYPE: mysql VIKUNJA_DATABASE_USER: vikunja VIKUNJA_DATABASE_DATABASE: vikunja VIKUNJA_SERVICE_JWTSECRET: [redacted] VIKUNJA_SERVICE_FRONTENDURL: https://tasks.example.com # env vars VIKUNJA_SERVICE_ENABLEREGISTRATION: "false" volumes: - ./files:/app/vikunja/files networks: - vikunja - npm_bridge depends_on: - db restart: unless-stopped frontend: image: vikunja/frontend:0.20.3 container_name: vikunja_frontend networks: - vikunja - npm_bridge restart: unless-stopped networks: vikunja: npm_bridge: external: true ``` ### Vikunja Frontend Version 0.20.3 ### Vikunja API Version 0.20.3 ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_
lluni added the
kind/bug
label 2023-03-11 00:33:23 +00:00
Owner

I was not able to reproduce this.

I've used this compose config, slightly adopted from yours:

version: '3'

services:
  db:
    image: mariadb:10
    container_name: vikunja_db
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    environment:
      MYSQL_ROOT_PASSWORD: pw
      MYSQL_USER: vikunja
      MYSQL_PASSWORD: pw
      MYSQL_DATABASE: vikunja
    volumes:
      - ./db:/var/lib/mysql
    restart: unless-stopped
    networks:
      - vikunja
  api:
    image: vikunja/api
    container_name: vikunja_api
    environment:
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_PASSWORD: pw
      VIKUNJA_DATABASE_TYPE: mysql
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_DATABASE: vikunja
      VIKUNJA_SERVICE_JWTSECRET: secret
      VIKUNJA_SERVICE_FRONTENDURL: https://tasks.example.com
      # env vars
      VIKUNJA_SERVICE_ENABLEREGISTRATION: "false"
    volumes:
      - ./files:/app/vikunja/files
    depends_on:
      - db
    networks:
      - vikunja
      - npm_bridge
    restart: unless-stopped
  frontend:
    image: vikunja/frontend:0.20.4
    container_name: vikunja_frontend
    restart: unless-stopped
    networks:
      - vikunja
      - npm_bridge

networks:
  vikunja:
  npm_bridge:
    external: true

And it seems to start up fine:

vikunja_frontend  | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
vikunja_frontend  | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
vikunja_frontend  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
vikunja_frontend  | 20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf
vikunja_frontend  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
vikunja_frontend  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/50-injector.sh
vikunja_frontend  | info: API URL is /api/v1
vikunja_frontend  | info: Sentry enabled: false
vikunja_frontend  | info: started at 2023-03-11T08:42:00+00:00
vikunja_frontend  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/60-ipv6-disable.sh
vikunja_frontend  | /docker-entrypoint.sh: Configuration complete; ready for start up

I don't have npm set up but the error you mentioned indicates a problem with the Vikunja frontend container, not npm.

Does this compose config work for you?

I was not able to reproduce this. I've used this compose config, slightly adopted from yours: ``` version: '3' services: db: image: mariadb:10 container_name: vikunja_db command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci environment: MYSQL_ROOT_PASSWORD: pw MYSQL_USER: vikunja MYSQL_PASSWORD: pw MYSQL_DATABASE: vikunja volumes: - ./db:/var/lib/mysql restart: unless-stopped networks: - vikunja api: image: vikunja/api container_name: vikunja_api environment: VIKUNJA_DATABASE_HOST: db VIKUNJA_DATABASE_PASSWORD: pw VIKUNJA_DATABASE_TYPE: mysql VIKUNJA_DATABASE_USER: vikunja VIKUNJA_DATABASE_DATABASE: vikunja VIKUNJA_SERVICE_JWTSECRET: secret VIKUNJA_SERVICE_FRONTENDURL: https://tasks.example.com # env vars VIKUNJA_SERVICE_ENABLEREGISTRATION: "false" volumes: - ./files:/app/vikunja/files depends_on: - db networks: - vikunja - npm_bridge restart: unless-stopped frontend: image: vikunja/frontend:0.20.4 container_name: vikunja_frontend restart: unless-stopped networks: - vikunja - npm_bridge networks: vikunja: npm_bridge: external: true ``` And it seems to start up fine: ``` vikunja_frontend | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration vikunja_frontend | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ vikunja_frontend | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh vikunja_frontend | 20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf vikunja_frontend | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh vikunja_frontend | /docker-entrypoint.sh: Launching /docker-entrypoint.d/50-injector.sh vikunja_frontend | info: API URL is /api/v1 vikunja_frontend | info: Sentry enabled: false vikunja_frontend | info: started at 2023-03-11T08:42:00+00:00 vikunja_frontend | /docker-entrypoint.sh: Launching /docker-entrypoint.d/60-ipv6-disable.sh vikunja_frontend | /docker-entrypoint.sh: Configuration complete; ready for start up ``` I don't have npm set up but the error you mentioned indicates a problem with the Vikunja frontend container, not npm. Does this compose config work for you?

I can reproduce the issue.

The cause is, that the docker container now runs as user nginx. This user does most likely not exist on many host systems and is therefore unprivileged (I also think this is what was intended by the change).
Most distributions don't allow binding to ports below 1024 without root privileges. As vikunja defaults to 80 this is the case.

I see 3 solutions to this problem:

  1. add nginx as a user with appropriate permissions to the host system. (I think this would mean that vikunja runs as a privileged container in the end)
  2. run vikunja as a privileged container again
  3. use a different port (example: 8080).

Here is the change for reference:
72a1aaa654/Dockerfile (L70)

I fixed it for myself by adding the following to the docker-compose file:

    environment:
      VIKUNJA_HTTP_PORT: 8080
      VIKUNJA_HTTP2_PORT: 8081

I can reproduce the issue. The cause is, that the docker container now runs as user nginx. This user does most likely not exist on many host systems and is therefore unprivileged (I also think this is what was intended by the change). Most distributions don't allow binding to ports below 1024 without root privileges. As vikunja defaults to 80 this is the case. I see 3 solutions to this problem: 1) add nginx as a user with appropriate permissions to the host system. (I think this would mean that vikunja runs as a privileged container in the end) 2) run vikunja as a privileged container again 3) use a different port (example: 8080). Here is the change for reference: https://kolaente.dev/vikunja/frontend/src/commit/72a1aaa654ac1bdd84625f96727ca46e30b00add/Dockerfile#L70 I fixed it for myself by adding the following to the docker-compose file: ``` environment: VIKUNJA_HTTP_PORT: 8080 VIKUNJA_HTTP2_PORT: 8081 ```
Owner

This user does most likely not exist on many host systems and is therefore unprivileged

But the user account exists in the docker container?

I don't have a user called nginx or one with a user id of 101 on my host system and I'm able to run the frontend container without issues.

What OS are you using?

> This user does most likely not exist on many host systems and is therefore unprivileged But the user account exists in the docker container? I don't have a user called `nginx` or one with a user id of `101` on my host system and I'm able to run the frontend container without issues. What OS are you using?
Owner

I dug a little and interestingly, the nginx process has the cap_net_bind_service linux capability. That means it should be able to run on ports < 1024 without being a root user.

I dug a little and interestingly, the nginx process has the `cap_net_bind_service` linux capability. That means it should be able to run on ports < 1024 without being a root user.
Owner

What Linux kernel are you running (with uname -a)? Which docker version? Which host OS and architecture?

What Linux kernel are you running (with `uname -a`)? Which docker version? Which host OS and architecture?
Author

@konrad If I see it correctly the only change in your config is that the newest frontend version is set explicitly, isn't it? That still results in the same logged error messages.

grissi-r's fix regarding changing the ports actually works for me as well.

I'm using Ubuntu 22.04.2 LTS, Linux 5.4.0, x86_64, Docker version 23.0.1 and Docker compose version v2.16.0.

@konrad If I see it correctly the only change in your config is that the newest frontend version is set explicitly, isn't it? That still results in the same logged error messages. grissi-r's fix regarding changing the ports actually works for me as well. I'm using Ubuntu 22.04.2 LTS, Linux 5.4.0, x86_64, Docker version 23.0.1 and Docker compose version v2.16.0.
Owner

If I see it correctly the only change in your config is that the newest frontend version is set explicitly, isn't it? That still results in the same logged error messages.

Yes that's correct. I just wanted to pin these versions.

I've tried something in e7b89ae44f. Can you pull the latest unstable docker image and check if that works for you? (On port 80 as original)

EDIT: still building

EDIT 2: build is done, please try

> If I see it correctly the only change in your config is that the newest frontend version is set explicitly, isn't it? That still results in the same logged error messages. Yes that's correct. I just wanted to pin these versions. I've tried something in https://kolaente.dev/vikunja/frontend/commit/e7b89ae44f86e72feddd00b948df4c6413e1384e. Can you pull the latest unstable docker image and check if that works for you? (On port 80 as original) EDIT: [still building](https://drone.kolaente.de/vikunja/frontend/12916) EDIT 2: build is done, please try

Hi,

For my case, I used the latest release (well watchtower updated automatically to the latest front) and I had the same issue.
I added the following environment variables to my docker compose :

  frontend:
    image: vikunja/frontend 
    ports:
      - 8062:80
    environment:
      VIKUNJA_API_URL: https://XXXXXXX/api/v1
**      VIKUNJA_HTTP_PORT: 8062
      VIKUNJA_HTTP2_PORT: 8063**
      UMASK: 000
      PUID: 1027
      GID: 100

Now the frontend starts without having the permission denied problem. Yet it's stuck on "/docker-entrypoint.sh: Configuration complete; ready for start up"

/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/20-envsubst-on-templates.sh
20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/50-injector.sh
info: API URL is https://XXXXXXX/api/v1
info: Sentry enabled: false
info: started at 2023-03-11T20:23:53+00:00
/docker-entrypoint.sh: Launching /docker-entrypoint.d/60-ipv6-disable.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
/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/20-envsubst-on-templates.sh
20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/50-injector.sh
info: API URL is https://XXXXXXXXXXX/api/v1
info: Sentry enabled: false
info: started at 2023-03-11T20:27:04+00:00
/docker-entrypoint.sh: Launching /docker-entrypoint.d/60-ipv6-disable.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
Hi, For my case, I used the latest release (well watchtower updated automatically to the latest front) and I had the same issue. I added the following environment variables to my docker compose : ``` frontend: image: vikunja/frontend ports: - 8062:80 environment: VIKUNJA_API_URL: https://XXXXXXX/api/v1 ** VIKUNJA_HTTP_PORT: 8062 VIKUNJA_HTTP2_PORT: 8063** UMASK: 000 PUID: 1027 GID: 100 ``` Now the frontend starts without having the permission denied problem. Yet it's stuck on "/docker-entrypoint.sh: Configuration complete; ready for start up" ``` /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/20-envsubst-on-templates.sh 20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/50-injector.sh info: API URL is https://XXXXXXX/api/v1 info: Sentry enabled: false info: started at 2023-03-11T20:23:53+00:00 /docker-entrypoint.sh: Launching /docker-entrypoint.d/60-ipv6-disable.sh /docker-entrypoint.sh: Configuration complete; ready for start up /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/20-envsubst-on-templates.sh 20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/50-injector.sh info: API URL is https://XXXXXXXXXXX/api/v1 info: Sentry enabled: false info: started at 2023-03-11T20:27:04+00:00 /docker-entrypoint.sh: Launching /docker-entrypoint.d/60-ipv6-disable.sh /docker-entrypoint.sh: Configuration complete; ready for start up ```
Owner

@raedkit That sounds like it should work. Are you able to reach it?

Can you check if the unstable version works with port 80? (as per my comment above)

@raedkit That sounds like it should work. Are you able to reach it? Can you check if the unstable version works with port 80? (as per my comment above)

@raedkit That sounds like it should work. Are you able to reach it?

Can you check if the unstable version works with port 80? (as per my comment above)

I will check with the unstable version and will let you know but I won't be able to test with port 80 as I'm on a Nas and this port is already used.

> @raedkit That sounds like it should work. Are you able to reach it? > > Can you check if the unstable version works with port 80? (as per my comment above) I will check with the unstable version and will let you know but I won't be able to test with port 80 as I'm on a Nas and this port is already used.
Owner

I meant without the VIKUNJA_HTTP_PORT env variable.

I meant without the `VIKUNJA_HTTP_PORT` env variable.

@raedkit That sounds like it should work. Are you able to reach it?

Can you check if the unstable version works with port 80? (as per my comment above)

I will check with the unstable version and will let you know but I won't be able to test with port 80 as I'm on a Nas and this port is already used.

I have the same problem with the unstable version. I will go back to 0.20.3 on the frontend until this problem is fixed.
@konrad If you need me to test anything please do not hesitate.

> > @raedkit That sounds like it should work. Are you able to reach it? > > > > Can you check if the unstable version works with port 80? (as per my comment above) > > I will check with the unstable version and will let you know but I won't be able to test with port 80 as I'm on a Nas and this port is already used. I have the same problem with the unstable version. I will go back to 0.20.3 on the frontend until this problem is fixed. @konrad If you need me to test anything please do not hesitate.
Owner

@raedkit New fix from 6cf2e574bf is published and packaged as unstable, please try again.

(still without the port config)

@raedkit New fix from https://kolaente.dev/vikunja/frontend/commit/6cf2e574bfcca6bf10d0465e9adf9e23d7b24367 is published and packaged as unstable, please try again. (still without the port config)

@raedkit New fix from 6cf2e574bf is published and packaged as unstable, please try again.

(still without the port config)

Thank you it's working as expected.
I retested now (without the port config) but with a different port than 80 (as explained above) and everything is OK :

  frontend:
    image: vikunja/frontend:unstable
    ports:
      - 8062:80
    environment:
      VIKUNJA_API_URL: https://XXXXXX/api/v1
      UMASK: 000
      PUID: 1027
      GID: 100
    restart: unless-stopped
> @raedkit New fix from https://kolaente.dev/vikunja/frontend/commit/6cf2e574bfcca6bf10d0465e9adf9e23d7b24367 is published and packaged as unstable, please try again. > > (still without the port config) Thank you it's working as expected. I retested now (without the port config) but with a different port than 80 (as explained above) and everything is OK : ``` frontend: image: vikunja/frontend:unstable ports: - 8062:80 environment: VIKUNJA_API_URL: https://XXXXXX/api/v1 UMASK: 000 PUID: 1027 GID: 100 restart: unless-stopped ```
Owner

That's awesome to hear. If there are no other finds, I'll publish a new version soon.

That's awesome to hear. If there are no other finds, I'll publish a new version soon.
Owner

Btw, the UMASK, PUID and GID don't have an effect.

Btw, the `UMASK`, `PUID` and `GID` don't have an effect.

That's awesome to hear. If there are no other finds, I'll publish a new version soon.

Perfect (y).
I will stick to the unstable until this version is released. I sent you also a mail. Could you have a look at it ? Thanks in advance.

> That's awesome to hear. If there are no other finds, I'll publish a new version soon. Perfect (y). I will stick to the unstable until this version is released. I sent you also a mail. Could you have a look at it ? Thanks in advance.
Owner

Should be fixed now.

Should be fixed now.
Author

Can confirm, unstable version 0.20.4+4-6cf2e574bf with port 80 works for me again.

Can confirm, unstable version `0.20.4+4-6cf2e574bf` with port `80` works for me again.
Owner

I've just released the fix - please update: https://vikunja.io/blog/2023/03/vikunja-frontend-v0.20.5-and-api-v0.20.4-was-released/

Going to close this issue now, thanks for everyone reporting and testing fixes.

I've just released the fix - please update: https://vikunja.io/blog/2023/03/vikunja-frontend-v0.20.5-and-api-v0.20.4-was-released/ Going to close this issue now, thanks for everyone reporting and testing fixes.
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/vikunja#2024
No description provided.