Selfhosting penpot: got problems of rendering/export

Self-host
1

Hi,

since yesterday I got problems rendering. I also can’t export anything or download the file as .penpot. I always get a 404 on some assets.

I’ve changed the assets volume from a bind to a docker volume checked file permissions but all seems fine. I also tried install it on a new folder but got same issues. I am using the latest penpot version. I migrated from 2.13 to 2.15 last week.

Thanks in advance

2

Hey, which version of penpot are you using?

3

I am using 2.15. I found out what the problem is. I tried the new wasm renderer with wasm=true in the url. Then all breaks when trying to download or render without the wasm renderer.

1 Like
4

Hi,

Using the render should not affect assets, it seems an issue with the assets storage. Could you please check the assets path or send some logs? We would need more details to try to understand the issue.

At v2.11.0 the `PENPOT_STORAGE_ASSETS_FS_DIRECTORY` was changed to `PENPOT_OBJECTS_STORAGE_FS_DIRECTORY`, I know the migration was from 2.13 to 2.15, but checking just in case.

5

i’ve checked and I use

PENPOT_OBJECTS_STORAGE_FS_DIRECTORY

 PENPOT_OBJECTS_STORAGE_BACKEND: fs
 PENPOT_OBJECTS_STORAGE_FS_DIRECTORY: /opt/data/assets

and in my compose:

volumes:

  • ${DOCKER_VOLUME_STORAGE:-/mnt/docker-volumes}/penpot2/assets:/opt/data/assets
6

The 404 response path would help debug the issue, it could be that files exist but backend looks for them at different subpath than where they were stored

7

what do you mean?

the url of a missing asset:

https://my-server/assets/by-id/1246ccf6-e4d9-4ebe-8376-ee68fe89931e

8

I meant the logs for the missing asset. Those would give us a clue about which path it’s expecting the assets to be in. Without that, it’s hard for us to tell what the issue is.

In the meantime, double-check that the volume path in your compose is correct, and that is the same on both penpot-backend and penpot-frontend.

9

the volume path of backend and frontend are the same: ${DOCKER_VOLUME_STORAGE:-/mnt/docker-volumes}/penpot2/assets:/opt/data/assets

I also found out that the volume is also mounted in exporter. Is this correct?

here are the last log lines: gist:9102dbf0491166baee3d9b362626b07f

10

Checking the logs, it seems there’s not enough permission to write to /opt/data/assets, so new upload fails. You would need to update the permissions (and maybe copy old files if necessary)

In any case, this does not seem related to the render change, we’re keeping an eye just in case, but it’s not the root cause

11

hmm. I installed it on a brand new folder and it had worked before I tried the new renderer. Are they any resources for the permission what to set?

12

maybe they were cached, it’s unlikely the render change affected the assets

you can try this:

  • `docker exec -u 0 penpot-backend-1 chown -R penpot:penpot /opt/data`
  • This could also help: `chown -R 1001:1001 /mnt/docker-volumes/penpot2/assets`

and then you’d have to restart both `penpot-backend` and `penpot-frontend`

(path might be different depending on your config)

13

both don’t work. I don’t know what to do. I moved already to a blank new directory before.

14

`1001` is usually the containers uid, but yours could be different

it’s complicated to dig into the problem without having the full picture, but I recommend opening an issue in our GitHub project including the following:

  • how to reproduce the error, step by step
  • full error trace
  • logs when possible
15

i’ve setup a local instance and imported a sql dump of the remote database. I got the same problems.

16

As mentioned above, to get through this it’s needed to open a detailed issue. We have this guideline: 01· Reporting bugs

17

I’ve found this: Assets storage

can I use the db for assets instead of relying on the filesystem?