Unable to upload images larger than ~1.5MB or view existing uploaded images #3857

New Issue

OVERLORD · 2026-02-05T07:41:30+03:00

OVERLORD commented

2026-02-05 07:41:30 +03:00

Originally created by @AvrumFeldman on GitHub (Jun 14, 2023).

Describe the Bug

When I try to upload an image which is larger than 1.5MB to a page by drag-n-drop I get the following error "An error occurred uploading the image". But I can confirm the images are actually uploaded, by checking /app/www/public/uploads/images/gallery/... and the images are also accessible by navigating to it from the browser http://bookstsackurl/uploads/images/gallery/...

In addition when I open the image menu non of the existing images are shown.

I somehow believe these two issues are related since I believe both happened at the same time.

This was working fine until now and suddenly stopped working without any changes from our end.

Steps to Reproduce

Open an existing page
drag an image larger than ~1.5MB from your computer onto the page, or open the image menu from the toolbar.

Expected Behaviour

Images should be uploaded and we should be able to see the previously uploaded images.

Screenshots or Additional Context

I checked the /app/www/storage/logs/laravel.log for errors and only got some older errors which I confirmed don't reoccur when I attempt to upload anything.

2023-06-14 14:00:03] production.ERROR: Allowed memory size of 134217728 bytes exhausted (tried to allocate 528384 bytes) {"userId":6,"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\FatalError(code: 0): Allowed memory size of 134217728 bytes exhausted (tried to allocate 528384 bytes) at /app/www/vendor/intervention/image/src/Intervention/Image/Gd/Decoder.php:137)
[stacktrace]
#0 {main}

/var/log/nginx/error.log is empty.

I confirmed the images permissions are fine

I can also confirm I was able in the past to upload even larger images (see screenshot of 7MB images)

Browser Details

No response

Exact BookStack Version

Our production version of bookstack is still v22.09.1 but I updated the container to v23.05.2 and still get the same issue.

PHP Version

No response

Hosting Environment

linuxserver/bookstack docker on virtualized (Hyper-V) ubuntu 20.04.3 LTS. Container storage is EXT4.

version: "2"
services:
  bookstack:
    image: linuxserver/bookstack:v23.05.2-ls85
    container_name: bookstack-staging-6-14-23
    environment:
      # container rights
      - PUID=1000
      - PGID=1000
      
      - APP_URL=<snip>
      
      # DB settings
      - DB_HOST=bookstack_db-staging-6-14-23
      - DB_USER=<snip>
      - DB_PASS=<snip>
      - DB_DATABASE=<snip>
      
      # Mail settings
      <snip>

    volumes:
      - /srv/backup/2023-06-14_30039/data:/config
    ports:
      - 61011:80
    restart: unless-stopped
    depends_on:
      - bookstack_db-staging-6-14-23
  bookstack_db-staging:
    image: mariadb:10.9.4-jammy
    container_name: bookstack_db-staging-6-14-23
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=<snip>
      - TZ=America/New_York
      - MYSQL_DATABASE=<snip>
      - MYSQL_USER=<snip>
      - MYSQL_PASSWORD=<snip>
    volumes:
      - /srv/backup/2023-06-14_30039/db:/config
      - /srv/backup/2023-06-14_30039/db-init:/docker-entrypoint-initdb.d
    restart: unless-stopped

Originally created by @AvrumFeldman on GitHub (Jun 14, 2023). ### Describe the Bug When I try to upload an image which is larger than 1.5MB to a page by drag-n-drop I get the following error "An error occurred uploading the image". But I can confirm the images are actually uploaded, by checking `/app/www/public/uploads/images/gallery/...` and the images are also accessible by navigating to it from the browser `http://bookstsackurl/uploads/images/gallery/...` ![chrome_p2UYKBULm5](https://github.com/BookStackApp/BookStack/assets/42219106/7566d901-372e-45f9-994d-748697ba471d) In addition when I open the image menu non of the existing images are shown. ![chrome_XHntDN0Yip](https://github.com/BookStackApp/BookStack/assets/42219106/29ee4367-4702-43f7-9a96-c2cfac9767be) I somehow believe these two issues are related since I believe both happened at the same time. This was working fine until now and suddenly stopped working without any changes from our end. ### Steps to Reproduce Open an existing page drag an image larger than ~1.5MB from your computer onto the page, or open the image menu from the toolbar. ### Expected Behaviour Images should be uploaded and we should be able to see the previously uploaded images. ### Screenshots or Additional Context I checked the `/app/www/storage/logs/laravel.log` for errors and only got some older errors which I confirmed don't reoccur when I attempt to upload anything. ``` 2023-06-14 14:00:03] production.ERROR: Allowed memory size of 134217728 bytes exhausted (tried to allocate 528384 bytes) {"userId":6,"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\FatalError(code: 0): Allowed memory size of 134217728 bytes exhausted (tried to allocate 528384 bytes) at /app/www/vendor/intervention/image/src/Intervention/Image/Gd/Decoder.php:137) [stacktrace] #0 {main} ``` `/var/log/nginx/error.log` is empty. I confirmed the images permissions are fine ![image](https://github.com/BookStackApp/BookStack/assets/42219106/173fb461-5c49-4910-a669-35742926fe24) I can also confirm I was able in the past to upload even larger images (see screenshot of 7MB images) ![image](https://github.com/BookStackApp/BookStack/assets/42219106/ae1b2963-b46a-4df1-b012-9d59e2dfeada) ### Browser Details _No response_ ### Exact BookStack Version Our production version of bookstack is still v22.09.1 but I updated the container to v23.05.2 and still get the same issue. ### PHP Version _No response_ ### Hosting Environment linuxserver/bookstack docker on virtualized (Hyper-V) ubuntu 20.04.3 LTS. Container storage is EXT4. ``` version: "2" services: bookstack: image: linuxserver/bookstack:v23.05.2-ls85 container_name: bookstack-staging-6-14-23 environment: # container rights - PUID=1000 - PGID=1000 - APP_URL=<snip> # DB settings - DB_HOST=bookstack_db-staging-6-14-23 - DB_USER=<snip> - DB_PASS=<snip> - DB_DATABASE=<snip> # Mail settings <snip> volumes: - /srv/backup/2023-06-14_30039/data:/config ports: - 61011:80 restart: unless-stopped depends_on: - bookstack_db-staging-6-14-23 bookstack_db-staging: image: mariadb:10.9.4-jammy container_name: bookstack_db-staging-6-14-23 environment: - PUID=1000 - PGID=1000 - MYSQL_ROOT_PASSWORD=<snip> - TZ=America/New_York - MYSQL_DATABASE=<snip> - MYSQL_USER=<snip> - MYSQL_PASSWORD=<snip> volumes: - /srv/backup/2023-06-14_30039/db:/config - /srv/backup/2023-06-14_30039/db-init:/docker-entrypoint-initdb.d restart: unless-stopped ```

OVERLORD added the 🐛 Bug label 2026-02-05 07:41:30 +03:00

OVERLORD closed this issue

2026-02-05 07:41:30 +03:00

OVERLORD commented

2026-02-05 07:41:36 +03:00

@ssddanbrown commented on GitHub (Jun 14, 2023):

This is very likely to be due to hitting a PHP memory limit.
Can you edit the /srv/backup/2023-06-14_30039/data/php/php-local.ini file and update the following:

If date.timezone is empty, update that to: date.timezone = UTC.
Append memory_limit = 256M to the file.

Then restart the container stack to pick up the changes and try again.

@ssddanbrown commented on GitHub (Jun 14, 2023): This is very likely to be due to hitting a PHP memory limit. Can you edit the `/srv/backup/2023-06-14_30039/data/php/php-local.ini` file and update the following: - If `date.timezone` is empty, update that to: `date.timezone = UTC`. - Append `memory_limit = 256M` to the file. Then restart the container stack to pick up the changes and try again.

OVERLORD commented

2026-02-05 07:41:38 +03:00

@AvrumFeldman commented on GitHub (Jun 14, 2023):

Thanks @ssddanbrown that fixed it.

I'm assuming this isn't the default because most people don't hit this limit. Is there a reason our instance did hit it?

@AvrumFeldman commented on GitHub (Jun 14, 2023): Thanks @ssddanbrown that fixed it. I'm assuming this isn't the default because most people don't hit this limit. Is there a reason our instance did hit it?

OVERLORD commented

2026-02-05 07:41:43 +03:00

@ssddanbrown commented on GitHub (Jun 14, 2023):

Good to hear! Will therefore close this off.

I'm assuming this isn't the default because most people don't hit this limit. Is there a reason our instance did hit it?

It would have been at 128M before which is just the PHP default.
The specific part it would have been failing at would be resizing images, which can munch through memory.
It can come down to the specific image though for how hungry it'll be for memory, a 1.5MB image can be hundreds of MB when decompressed into memory.

@ssddanbrown commented on GitHub (Jun 14, 2023): Good to hear! Will therefore close this off. > I'm assuming this isn't the default because most people don't hit this limit. Is there a reason our instance did hit it? It would have been at 128M before which is just the PHP default. The specific part it would have been failing at would be resizing images, which can munch through memory. It can come down to the specific image though for how hungry it'll be for memory, a 1.5MB image can be hundreds of MB when decompressed into memory.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#3857