starred/planka
1
0
Fork 0
mirror of https://github.com/plankanban/planka.git synced 2026-02-24 19:08:59 +03:00
Code Issues 396 Packages Projects Releases 16 Wiki Activity

[Bug]: Did something break DATABASE_PASSWORD__FILE recently? #741

New Issue
Closed
opened 2026-02-04 21:10:18 +03:00 by OVERLORD · 5 comments
OVERLORD commented 2026-02-04 21:10:18 +03:00
Owner
Copy Link

Originally created by @solomon-b on GitHub (Jun 23, 2025).

Where is the problem occurring?

When booting the service.

What browsers are you seeing the problem on?

No response

Current behavior

I hadn't updated in a while and now DATABASE_PASSWORD__FILE doesn't seem to work correctly.

I can see my password mounted in the container:

➜ docker exec -it planka ls -la /run/secrets/planka-database-password
-r--r--r--    1 root     root             7 Jun 23 02:07 /run/secrets/planka-database-password

➜ docker exec -it planka cat /run/secrets/planka-database-password             
<redacted-but-correct-password-value>

Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: /app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/parser.js:283
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:         const message = name === 'notice' ? new messages_1.NoticeMessage(length, messageValue) : new messages_1.DatabaseError(messageValue, l>
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:                                                                                                  ^
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: error: password authentication failed for user "planka_admin"
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:     at Parser.parseErrorMessage (/app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/parser.js:283:98)
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:     at Parser.handlePacket (/app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/parser.js:122:29)
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:     at Parser.parse (/app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/parser.js:35:38)
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:     at Socket.<anonymous> (/app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/index.js:11:42)
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:     at Socket.emit (node:events:517:28)
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:     at addChunk (node:internal/streams/readable:368:12)
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:     at readableAddChunk (node:internal/streams/readable:341:9)
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:     at Readable.push (node:internal/streams/readable:278:10)
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:     at TCP.onStreamRead (node:internal/stream_base_commons:190:23) {
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   length: 108,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   severity: 'FATAL',
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   code: '28P01',
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   detail: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   hint: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   position: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   internalPosition: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   internalQuery: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   where: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   schema: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   table: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   column: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   dataType: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   constraint: undefined,
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   file: 'auth.c',
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   line: '338',
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]:   routine: 'auth_failed'
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: }
Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: Node.js v18.20.4
Jun 22 19:11:15 accompaniment-of-shadows systemd[1]: docker-planka.service: Main process exited, code=exited, status=1/FAILURE

If I hard code the password in the connection string then Planka works as expected.

Desired behavior

I would expect the password to be interpolated into the connections string and used for auth. This was working previously.

Steps to reproduce

I mounted my secrets as volumes in the docker container. Then I used DATABASE_PASSWORD__FILE to specifiy the path to the DB password secret. Lastly I set the connection string to use the secret: "postgresql://planka_admin:${DATABASE_PASSWORD}@transfigured-night/planka"

Other information

No response

Originally created by @solomon-b on GitHub (Jun 23, 2025). ### Where is the problem occurring? When booting the service. ### What browsers are you seeing the problem on? _No response_ ### Current behavior I hadn't updated in a while and now `DATABASE_PASSWORD__FILE` doesn't seem to work correctly. I can see my password mounted in the container: ``` ➜ docker exec -it planka ls -la /run/secrets/planka-database-password -r--r--r-- 1 root root 7 Jun 23 02:07 /run/secrets/planka-database-password ➜ docker exec -it planka cat /run/secrets/planka-database-password <redacted-but-correct-password-value> ``` ``` Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: /app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/parser.js:283 Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: const message = name === 'notice' ? new messages_1.NoticeMessage(length, messageValue) : new messages_1.DatabaseError(messageValue, l> Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: ^ Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: error: password authentication failed for user "planka_admin" Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: at Parser.parseErrorMessage (/app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/parser.js:283:98) Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: at Parser.handlePacket (/app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/parser.js:122:29) Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: at Parser.parse (/app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/parser.js:35:38) Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: at Socket.<anonymous> (/app/node_modules/.pnpm/pg-protocol@1.6.1/node_modules/pg-protocol/dist/index.js:11:42) Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: at Socket.emit (node:events:517:28) Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: at addChunk (node:internal/streams/readable:368:12) Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: at readableAddChunk (node:internal/streams/readable:341:9) Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: at Readable.push (node:internal/streams/readable:278:10) Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: at TCP.onStreamRead (node:internal/stream_base_commons:190:23) { Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: length: 108, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: severity: 'FATAL', Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: code: '28P01', Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: detail: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: hint: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: position: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: internalPosition: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: internalQuery: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: where: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: schema: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: table: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: column: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: dataType: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: constraint: undefined, Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: file: 'auth.c', Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: line: '338', Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: routine: 'auth_failed' Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: } Jun 22 19:11:14 accompaniment-of-shadows docker-planka-start[385121]: Node.js v18.20.4 Jun 22 19:11:15 accompaniment-of-shadows systemd[1]: docker-planka.service: Main process exited, code=exited, status=1/FAILURE ``` If I hard code the password in the connection string then Planka works as expected. ### Desired behavior I would expect the password to be interpolated into the connections string and used for auth. This was working previously. ### Steps to reproduce I mounted my secrets as volumes in the docker container. Then I used `DATABASE_PASSWORD__FILE` to specifiy the path to the DB password secret. Lastly I set the connection string to use the secret: `"postgresql://planka_admin:${DATABASE_PASSWORD}@transfigured-night/planka"` ### Other information _No response_
OVERLORD commented 2026-02-04 21:10:35 +03:00
Author
Owner
Copy Link

@fitztrev commented on GitHub (Jun 27, 2025):

I ran into this and it's because of read (in start.sh) trying to put the contents into the environment variable.

If the secret file does not contain a newline it silently fails. The quick solution for me was to update the secret values to contain a trailing newline.

ref https://github.com/plankanban/planka/pull/1132 cc @iosabi

@fitztrev commented on GitHub (Jun 27, 2025): I ran into this and it's because of `read` ([in start.sh](https://github.com/plankanban/planka/blob/b37fc61b12ba0b8f3fd7f50f61f062570d43ada5/server/start.sh#L11)) trying to put the contents into the environment variable. If the secret file does not contain a newline it silently fails. The quick solution for me was to update the secret values to contain a trailing newline. ref https://github.com/plankanban/planka/pull/1132 cc @iosabi
OVERLORD commented 2026-02-04 21:10:46 +03:00
Author
Owner
Copy Link

@iosabi commented on GitHub (Jul 30, 2025):

Thanks @meltyshev for pushing a fix. I however wasn't able to reproduce that behavior:

docker run -it --rm --entrypoint /bin/bash -- ghcr.io/plankanban/planka:latest -c 'echo -n testpwd > /tmp/secret_file; testvar=nothing; read testvar < /tmp/secret_file ; echo "testvar=${testvar}"'

prints:

testvar=testpwd

The /tmp/secret_file doesn't have a newline because it is generated with echo -n.

It could be that the password @solomon-b was using had a backslash somewhere in the middle, which read will interpret unless we use read -r (which I should have done, sorry). Either way, if head -n 1 works then fine with me.

@iosabi commented on GitHub (Jul 30, 2025): Thanks @meltyshev for pushing a fix. I however wasn't able to reproduce that behavior: ``` docker run -it --rm --entrypoint /bin/bash -- ghcr.io/plankanban/planka:latest -c 'echo -n testpwd > /tmp/secret_file; testvar=nothing; read testvar < /tmp/secret_file ; echo "testvar=${testvar}"' ``` prints: ``` testvar=testpwd ``` The /tmp/secret_file doesn't have a newline because it is generated with `echo -n`. It could be that the password @solomon-b was using had a backslash somewhere in the middle, which `read` will interpret unless we use `read -r` (which I should have done, sorry). Either way, if `head -n 1` works then fine with me.
OVERLORD commented 2026-02-04 21:10:56 +03:00
Author
Owner
Copy Link

@meltyshev commented on GitHub (Jul 30, 2025):

Thanks @meltyshev for pushing a fix. I however wasn't able to reproduce that behavior:

docker run -it --rm --entrypoint /bin/bash -- ghcr.io/plankanban/planka:latest -c 'echo -n testpwd > /tmp/secret_file; testvar=nothing; read testvar < /tmp/secret_file ; echo "testvar=${testvar}"'

prints:

testvar=testpwd

The /tmp/secret_file doesn't have a newline because it is generated with echo -n.

It could be that the password @solomon-b was using had a backslash somewhere in the middle, which read will interpret unless we use read -r (which I should have done, sorry). Either way, if head -n 1 works then fine with me.

Hey! To be honest, I'm not entirely sure why it fails without a newline at the end. But when I tried to reproduce it by creating a secret file without a trailing newline, the container kept restarting without any errors in the logs.

I just tried your test command and got the same result as you. However, if I add set -e at the beginning (as we have in start.sh) - it silently fails. Still, it's hard for me to say exactly why it behaves like that 😄

@meltyshev commented on GitHub (Jul 30, 2025): > Thanks [@meltyshev](https://github.com/meltyshev) for pushing a fix. I however wasn't able to reproduce that behavior: > > ``` > docker run -it --rm --entrypoint /bin/bash -- ghcr.io/plankanban/planka:latest -c 'echo -n testpwd > /tmp/secret_file; testvar=nothing; read testvar < /tmp/secret_file ; echo "testvar=${testvar}"' > ``` > > prints: > > ``` > testvar=testpwd > ``` > > The /tmp/secret_file doesn't have a newline because it is generated with `echo -n`. > > It could be that the password [@solomon-b](https://github.com/solomon-b) was using had a backslash somewhere in the middle, which `read` will interpret unless we use `read -r` (which I should have done, sorry). Either way, if `head -n 1` works then fine with me. Hey! To be honest, I'm not entirely sure why it fails without a newline at the end. But when I tried to reproduce it by creating a secret file without a trailing newline, the container kept restarting without any errors in the logs. I just tried your test command and got the same result as you. However, if I add `set -e` at the beginning (as we have in `start.sh`) - it silently fails. Still, it's hard for me to say exactly why it behaves like that 😄
OVERLORD commented 2026-02-04 21:11:04 +03:00
Author
Owner
Copy Link

@iosabi commented on GitHub (Jul 31, 2025):

Aaaah, that explains it. read return non-zero on EOF.

From the bash manual:

The exit status is zero, unless end-of-file is encountered, ...

It is interesting that read does the thing it is meant to do (read the value into the variable) in addition to returning an error... oh well... bash. Sorry for introducing a bunch of bash I guess =^.^=

@iosabi commented on GitHub (Jul 31, 2025): Aaaah, that explains it. `read` return non-zero on EOF. From the [bash manual](https://www.gnu.org/software/bash/manual/bash.html#index-read): > The exit status is zero, unless end-of-file is encountered, ... It is interesting that `read` does the thing it is meant to do (read the value into the variable) **in addition to** returning an error... oh well... bash. Sorry for introducing a bunch of bash I guess =^.^=
OVERLORD commented 2026-02-04 21:11:10 +03:00
Author
Owner
Copy Link

@meltyshev commented on GitHub (Jul 31, 2025):

Aaaah, that explains it. read return non-zero on EOF.

From the bash manual:

The exit status is zero, unless end-of-file is encountered, ...

It is interesting that read does the thing it is meant to do (read the value into the variable) in addition to returning an error... oh well... bash. Sorry for introducing a bunch of bash I guess =^.^=

Ah, thanks for the info - that's really interesting to know! And no worries at all, everything's totally fine :)

@meltyshev commented on GitHub (Jul 31, 2025): > Aaaah, that explains it. `read` return non-zero on EOF. > > From the [bash manual](https://www.gnu.org/software/bash/manual/bash.html#index-read): > > > The exit status is zero, unless end-of-file is encountered, ... > > It is interesting that `read` does the thing it is meant to do (read the value into the variable) **in addition to** returning an error... oh well... bash. Sorry for introducing a bunch of bash I guess =^.^= Ah, thanks for the info - that's really interesting to know! And no worries at all, everything's totally fine :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
documentation
documentation
duplicate
enhancement
good first issue
help wanted
pull-request
Mirrored from GitHub Pull Request
 question
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/planka#741
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?