Changing Max Attachment Size

Here is what you need to do to allow more than 10mb for attachments upload.

  1. Connect to your server via SSH

  2. cd /var/discourse/

  3. nano containers/app.yml

  4. Scroll down where it says db_default_text_search_config under params

Add upload_size: 20m below db_default_text_search_config

  db_default_text_search_config: "pg_catalog.english"

  # replace 20m with desired value
  upload_size: 20m

After making changes press Ctrl+O (to write) and Ctrl+X (to exit).

From /var/discourse run:

./launcher rebuild app

Once rebuild is complete, navigate to and change the max attachment size kb to 20480 (20mb) or your desired number. At this point everything should work perfectly, you can go on and test your upload file size.



I’ve followed these instructions but when I send an email to my category with an attachment with around 9mb, I get:

Message too large

Your message couldn’t be delivered to [] because it exceeds the size limit. Try reducing the message size and resending.
The response from the remote server was:

552 5.3.4 Message size exceeds fixed limit

P.S. [] is a “category” email

This is completely unrelated to Discourse, that error is coming from your mail server. The mail server is not even handing the mail over to Discourse it is rejecting it.


Thanks for pointing this out Sam. From your answer I went on and took another look and managed to someway fix this issue.
I started by questioning if this was on sender or receiver side. Sender was gmail and the limit was 25 mb so it couldn’t be there. Receiver was mail_receiver.
Below a link where I also share what I’ve done in case someone faces a similar issue.

I’ve done this but can’t make it work

I checked after rebuild that in the container the nginx conf file correctly has the client_max_body_size 200m ;

Since I have a multi-site server configuration as shown in Running other websites on the same machine as Discourse I also added the line client_max_body_size 200m ; in the outer nginx conf and restart

but I still have max_attachment_size_kb: Value must be between 0 and 1024000.

any other setting to change ?

1 Like

Should this still work? I changed upload_size: 25m, rebuilt, confirmed that it was set in /etc/nginx/conf.d/discourse.conf, but when I try to change the max attachment size kb I still get max_attachment_size_kb: Value must be between 0 and 1024000. This is a subfolder install behind an Apache reverse proxy (seemed like a good idea at the time), but max there is 200MB).

There is lots of discussion like Upload_size in app.yml not working and Error with very large file uploading, but those are different problems (mostly unicorn or other components crapping out because they can’t handle it).

Rails says:

Discourse::InvalidParameters: max_attachment_size_kb: Value must be between 0 and 1024000.
from /var/www/discourse/lib/site_settings/type_supervisor.rb:215:in `validate_value'

I poked around but can’t quite tell how it’s determined what the max max attachment size can be.

This is still a problem. A client just asked that I change the max upload size. I see that it’s already set in the app.yml as prescribed, but like I just noticed that I said 4 months ago, it doesn’t work.

I’ve changed upload_size and confirmed that it’s modified in /etc/nginx/conf.d/discourse.conf, but trying to change the max attachment size kb still claims: “max_attachment_size_kb: Value must be between 0 and 1024000.”

My solution is to edit site_settings.yml inside the container, but I guess that some template should be updated to do that (if these instructions are to work) or to have app.yml re-write

    client: true
    default: 4096
    max: 1024000


    client: true
    default: 4096
    max: [$upload_size * 102400]

but I don’t have the pups chops to figure that out right now.

Is there a reason not to up the max value (and corresponding nginx setting) to 25M or so and leave the default at 10M?

My guess is this is specific to our hosting (upload sizes are limited per tier, standard starts at 10mb), but also not a great idea to encourage “hey I can use this thing as dropbox” in general.

Yeah. I get that, but it used to work. Maybe a simple solution (and presumably what you do?) is have a plugin that overrides the site setting?

I do support eventually allowing this to be higher, but we need to do direct attachment uploads to s3 prior to changing this default restriction. For now I guess you patch it in using your template.


I like the idea of direct uploads to S3!

If it could be overridden with an env (I can’t remember what we call that right now) then maybe it wouldn’t break your world and I wouldn’t need to patch it.

Could I submit that PR?

1 Like