starred/planka
1
0
Fork 0
mirror of https://github.com/plankanban/planka.git synced 2026-02-05 00:39:58 +03:00
Code Issues 396 Packages Projects Releases 10 Wiki Activity

[Bug]: User Avatar is not persisted in v2 #771

New Issue
Open
opened 2026-02-04 21:16:50 +03:00 by OVERLORD · 9 comments
OVERLORD commented 2026-02-04 21:16:50 +03:00
Owner
Copy Link

Originally created by @Maddin-M on GitHub (Aug 2, 2025).

Where is the problem occurring?

I encountered the problem while using the application (Frontend)

What browsers are you seeing the problem on?

Firefox

Current behavior

Hello,
I have updated to Planka 2.0.0-rc2 a few weeks ago (and now to rc3) and have noticed, that after restarting the pod (running in Kubernetes) my user avatars are gone. After investigating this for a bit, I can see that the user-avatars dir is indeed empty, even when setting an avatar. other directories like attachments or background-images do not have this problem, those are stored properly.
I have also changed nothing with the volumeMounts inbetween updating (except for the changes in this article).
The frontend does look for the avatar in url("http://<base-url>/user-avatars/f5bf40c7-5fcd-451d-9e91-8e2e263e2d68/cover-180.png") but it's never created.

Desired behavior

User avatars should be persisted using the given mounted volume.

Steps to reproduce

  1. Start Planka
  2. Login and set a user avatar
  3. Restart the Pod
  4. Avatar is now gone

Other information

I am happy to provide further information if needed.

Originally created by @Maddin-M on GitHub (Aug 2, 2025). ### Where is the problem occurring? I encountered the problem while using the application (Frontend) ### What browsers are you seeing the problem on? Firefox ### Current behavior Hello, I have updated to Planka 2.0.0-rc2 a few weeks ago (and now to rc3) and have noticed, that after restarting the pod (running in Kubernetes) my user avatars are gone. After investigating this for a bit, I can see that the `user-avatars` dir is indeed empty, even when setting an avatar. other directories like `attachments` or `background-images` do not have this problem, those are stored properly. I have also changed nothing with the volumeMounts inbetween updating (except for the changes in this [article](https://docs.planka.cloud/docs/upgrade-to-v2/docker#4-add-new-volumes)). The frontend does look for the avatar in `url("http://<base-url>/user-avatars/f5bf40c7-5fcd-451d-9e91-8e2e263e2d68/cover-180.png")` but it's never created. ### Desired behavior User avatars should be persisted using the given mounted volume. ### Steps to reproduce 1. Start Planka 2. Login and set a user avatar 3. Restart the Pod 4. Avatar is now gone ### Other information I am happy to provide further information if needed.
OVERLORD added the help wanted label 2026-02-04 21:16:50 +03:00
OVERLORD commented 2026-02-04 21:17:12 +03:00
Author
Owner
Copy Link

@sivertillia commented on GitHub (Aug 2, 2025):

@Maddin-M go to s3 from Aws or hetzner it will be a better choice

@sivertillia commented on GitHub (Aug 2, 2025): @Maddin-M go to `s3` from `Aws` or `hetzner` it will be a better choice
OVERLORD commented 2026-02-04 21:17:17 +03:00
Author
Owner
Copy Link

@meltyshev commented on GitHub (Aug 2, 2025):

Hi! That sounds strange... It seems like the volume isn't being mapped to the container, so everything gets lost when it restarts. But it's hard to say exactly what's wrong without seeing your configuration.

@meltyshev commented on GitHub (Aug 2, 2025): Hi! That sounds strange... It seems like the volume isn't being mapped to the container, so everything gets lost when it restarts. But it's hard to say exactly what's wrong without seeing your configuration.
OVERLORD commented 2026-02-04 21:17:19 +03:00
Author
Owner
Copy Link

@Maddin-M commented on GitHub (Aug 5, 2025):

@sivertillia I am hosting this on my bare metal homelab, thus persisting on my NAS atm, no cloud hoster.

@meltyshev This is my config: https://pastebin.com/zbk3qvsv

@Maddin-M commented on GitHub (Aug 5, 2025): @sivertillia I am hosting this on my bare metal homelab, thus persisting on my NAS atm, no cloud hoster. @meltyshev This is my config: https://pastebin.com/zbk3qvsv
OVERLORD commented 2026-02-04 21:17:25 +03:00
Author
Owner
Copy Link

@meltyshev commented on GitHub (Aug 8, 2025):

@meltyshev This is my config: https://pastebin.com/zbk3qvsv

Oops, I missed the fact that you're using Kubernetes - so it's a bit hard for me to diagnose the problem 🙈
But I hope someone else can help figure out why it might be happening.

@meltyshev commented on GitHub (Aug 8, 2025): > @meltyshev This is my config: https://pastebin.com/zbk3qvsv Oops, I missed the fact that you're using Kubernetes - so it's a bit hard for me to diagnose the problem 🙈 But I hope someone else can help figure out why it might be happening.
OVERLORD commented 2026-02-04 21:17:31 +03:00
Author
Owner
Copy Link

@Kosette commented on GitHub (Sep 29, 2025):

I can see that the user-avatars dir is indeed empty, even when setting an avatar.

If you mean that user-avatars dir empty even after setting up avatar from web interface, you could check permission for mounted volume, I don't know much about k8s, but for Docker if mounting an existing dir into container, owner should be 1000, otherwise nothing will be saved.

Referring to https://docs.planka.cloud/docs/installation/docker/production-version#additional-info

@Kosette commented on GitHub (Sep 29, 2025): > I can see that the user-avatars dir is indeed empty, even when setting an avatar. If you mean that `user-avatars` dir empty even after setting up avatar from web interface, you could check permission for mounted volume, I don't know much about k8s, but for Docker if mounting an existing dir into container, owner should be 1000, otherwise nothing will be saved. Referring to https://docs.planka.cloud/docs/installation/docker/production-version#additional-info
OVERLORD commented 2026-02-04 21:17:35 +03:00
Author
Owner
Copy Link

@Maddin-M commented on GitHub (Oct 6, 2025):

Yes, I have set:

securityContext:
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000

and also the env variables:

PGID=1000
PUID=1000

Still nothing. I also cannot see logs at all. When execing into the pod and printing the contents of the /logs dir, the files are empty.

@Maddin-M commented on GitHub (Oct 6, 2025): Yes, I have set: ```yaml securityContext: runAsUser: 1000 runAsGroup: 1000 fsGroup: 1000 ``` and also the env variables: ``` PGID=1000 PUID=1000 ``` Still nothing. I also cannot see logs at all. When execing into the pod and printing the contents of the `/logs` dir, the files are empty.
OVERLORD commented 2026-02-04 21:17:38 +03:00
Author
Owner
Copy Link

@Dionis-90 commented on GitHub (Oct 19, 2025):

Hello. I have the same problem after the upgrade with manual installation.
When I ran the db:upgrade I got an error

> db:upgrade
> node db/upgrade.js

Upgrading user avatars... [FAIL]
TypeError: fileManager.getSize is not a function
    at upgradeUserAvatars (/var/www/planka/db/upgrade.js:614:40)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async runStep (/var/www/planka/db/upgrade.js:63:5)
    at async /var/www/planka/db/upgrade.js:922:5
@Dionis-90 commented on GitHub (Oct 19, 2025): Hello. I have the same problem after the upgrade with manual installation. When I ran the db:upgrade I got an error ``` > db:upgrade > node db/upgrade.js Upgrading user avatars... [FAIL] TypeError: fileManager.getSize is not a function at upgradeUserAvatars (/var/www/planka/db/upgrade.js:614:40) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async runStep (/var/www/planka/db/upgrade.js:63:5) at async /var/www/planka/db/upgrade.js:922:5 ```
OVERLORD commented 2026-02-04 21:17:42 +03:00
Author
Owner
Copy Link

@meltyshev commented on GitHub (Oct 20, 2025):

Hello. I have the same problem after the upgrade with manual installation. When I ran the db:upgrade I got an error

> db:upgrade
> node db/upgrade.js

Upgrading user avatars... [FAIL]
TypeError: fileManager.getSize is not a function
    at upgradeUserAvatars (/var/www/planka/db/upgrade.js:614:40)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async runStep (/var/www/planka/db/upgrade.js:63:5)
    at async /var/www/planka/db/upgrade.js:922:5

Hey! Thanks for reporting this. It looks like you're using the nightly upgrade script with the latest version of everything else. We renamed the old method getSizeInBytes to just getSize - that change was made in both the upgrade script and the file manager, so they should be in sync. However, we haven't released the new version yet, so this change shouldn't be in the latest release. I'd suggest trying the process again from scratch.

Alternatively, you can use the nightly version, but the steps are a bit different - you'll need to build the frontend first (as shown here: https://docs.planka.cloud/docs/installation/manual/nightly_version/debian-and-ubuntu
), then copy over your previous files and attachments from v1, and finally run the upgrade script.

@meltyshev commented on GitHub (Oct 20, 2025): > Hello. I have the same problem after the upgrade with manual installation. When I ran the db:upgrade I got an error > > ``` > > db:upgrade > > node db/upgrade.js > > Upgrading user avatars... [FAIL] > TypeError: fileManager.getSize is not a function > at upgradeUserAvatars (/var/www/planka/db/upgrade.js:614:40) > at process.processTicksAndRejections (node:internal/process/task_queues:105:5) > at async runStep (/var/www/planka/db/upgrade.js:63:5) > at async /var/www/planka/db/upgrade.js:922:5 > ``` Hey! Thanks for reporting this. It looks like you're using the `nightly` upgrade script with the `latest` version of everything else. We renamed the old method `getSizeInBytes` to just `getSize` - that change was made in both the upgrade script and the file manager, so they should be in sync. However, we haven't released the new version yet, so this change shouldn't be in the `latest` release. I'd suggest trying the process again from scratch. Alternatively, you can use the `nightly` version, but the steps are a bit different - you'll need to build the frontend first (as shown here: https://docs.planka.cloud/docs/installation/manual/nightly_version/debian-and-ubuntu ), then copy over your previous files and attachments from v1, and finally run the upgrade script.
OVERLORD commented 2026-02-04 21:17:44 +03:00
Author
Owner
Copy Link

@Dionis-90 commented on GitHub (Oct 20, 2025):

Hello. I have the same problem after the upgrade with manual installation. When I ran the db:upgrade I got an error

> db:upgrade
> node db/upgrade.js

Upgrading user avatars... [FAIL]
TypeError: fileManager.getSize is not a function
    at upgradeUserAvatars (/var/www/planka/db/upgrade.js:614:40)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async runStep (/var/www/planka/db/upgrade.js:63:5)
    at async /var/www/planka/db/upgrade.js:922:5

Hey! Thanks for reporting this. It looks like you're using the nightly upgrade script with the latest version of everything else. We renamed the old method getSizeInBytes to just getSize - that change was made in both the upgrade script and the file manager, so they should be in sync. However, we haven't released the new version yet, so this change shouldn't be in the latest release. I'd suggest trying the process again from scratch.

Alternatively, you can use the nightly version, but the steps are a bit different - you'll need to build the frontend first (as shown here: https://docs.planka.cloud/docs/installation/manual/nightly_version/debian-and-ubuntu ), then copy over your previous files and attachments from v1, and finally run the upgrade script.

Thank you. I have run the release version of the upgrade.js. And the issue has been resolved.
I used the nightly version of upgrade.js because of this issue https://github.com/plankanban/planka/issues/1280

@Dionis-90 commented on GitHub (Oct 20, 2025): > > Hello. I have the same problem after the upgrade with manual installation. When I ran the db:upgrade I got an error > > ``` > > > db:upgrade > > > node db/upgrade.js > > > > Upgrading user avatars... [FAIL] > > TypeError: fileManager.getSize is not a function > > at upgradeUserAvatars (/var/www/planka/db/upgrade.js:614:40) > > at process.processTicksAndRejections (node:internal/process/task_queues:105:5) > > at async runStep (/var/www/planka/db/upgrade.js:63:5) > > at async /var/www/planka/db/upgrade.js:922:5 > > ``` > > Hey! Thanks for reporting this. It looks like you're using the `nightly` upgrade script with the `latest` version of everything else. We renamed the old method `getSizeInBytes` to just `getSize` - that change was made in both the upgrade script and the file manager, so they should be in sync. However, we haven't released the new version yet, so this change shouldn't be in the `latest` release. I'd suggest trying the process again from scratch. > > Alternatively, you can use the `nightly` version, but the steps are a bit different - you'll need to build the frontend first (as shown here: https://docs.planka.cloud/docs/installation/manual/nightly_version/debian-and-ubuntu ), then copy over your previous files and attachments from v1, and finally run the upgrade script. Thank you. I have run the release version of the upgrade.js. And the issue has been resolved. I used the nightly version of upgrade.js because of this issue https://github.com/plankanban/planka/issues/1280
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 help wanted
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#771
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?