Can't upload files via Drag and drop or browse for files
Asked by TorIX Operations:

Hi team,

What is really strange is that uploading seems to have ceased to work randomly and I can't quite pinpoint what the issue is. I went through some of the support documents which refer to ensuring the upload size is right, filenames are proper and making sure the baseURL is correct and in each situation they are all good to go.

I can see the file uploading in chrome (I've tried FF and Vivaldi, no luck), and once it hits 100% the page appears to refresh but no new files are posted.


Answers:
author: AnnWorley
body: I understand you aren't seeing an error message when you try to upload attachments in Confluence. Using Chrome, the files appear to upload but do not appear in the attachment list when you refresh the page. You have checked the base URL.

Please let us know more about the issue. Is there any error in   
\<confluence_home\>/logs/atlassian-confluence.log when you upload a file?  
Note: The \<confluence_home\> directory is the path defined in the following file: \<confluence_install\>/confluence/WEB-INF/classes/confluence-init.properties

Please also check the Chrome dev tools console for errors. You can launch it by right clicking and choosing Inspect.

If you have a chance during off hours, you might try plugin safe mode to make sure user installed plugins are not interfering: [Disabling or enabling all add-ons (using Safe Mode)](https://confluence.atlassian.com/upm/disabling-and-enabling-add-ons-273875716.html#Disablingandenablingadd-ons-Disablingorenablingalladd-ons(usingSafeMode)) All the macros provided by plugins will be unavailable while in safe mode.

If there is a reverse proxy in front of Confluence it would be a good idea to test uploading files while bypassing the proxy. Please see [How to bypass a Proxy and SSL to test network connectivity](https://confluence.atlassian.com/confkb/how-do-i-bypass-a-proxy-to-test-network-connectivity-402031184.html)

I look forward to hearing what you find.

comments: author: TorIX Operations
body: Hi Ann, Thanks for getting back to me!

We do use reverse proxy however the file has not been touched since April of this year (back I think when synchrony changes were required in the proxy).

I did find the following in the nginx error logs:

"29584 client intended to send too large body"

What I'm trying to figure out is if this maybe started to become an issue after migrating from 6.3.1 to 6.3.3 for some reason. The first instance of this error shows up Aug 21st which would have been when the upgrade was done based on our process list of when confluence started up again.

When I added the following configuration into nginx's vhost config for the site everything worked fine again:

```
client_max_body_size 200M;?
```


author: AnnWorley
body: Thanks for sharing the resolution! It is hinted at in our doc;

[Running Confluence behind NGINX with SSL](https://confluence.atlassian.com/doc/running-confluence-behind-nginx-with-ssl-858772080.html):
> ...make sure that the client_max_body_size in the /confluence location block matches Confluence's maximum attachment size. You may also need to increase the client_max_body_size in the /synchrony location block if you experience errors when editing large pages.

My Confluence 6.3.3 test instance has the maximum attachment size set to 100 MB; please let me know what yours is set to. It is on the Confluence Admin\>General Configuration page.

Do you also experience errors when editing large pages?


author: TorIX Operations
body: I have it set to 100M right now inside of the confluence configuration.

We don't have enough pages / large enough pages to make that big of a difference I suspect.


author: AnnWorley
body: Thanks for letting me know. May I ask: Was client_max_body_size set to 100M before you changed it to 200M?


author: TorIX Operations
body: The setting was not implemented at all in our configurations. Somehow we must have missed the config line when originally implementing this and it's finally caught up with us.

Thanks for pointing us in the right direciton Ann!