Expected behavior when uploading a new version of an attachment in Confluence?

Jenn Leaver October 30, 2013

Would someone be able to tell me if this is expected behavior?

I'm running Confluence 5.3. When I upload a new version of an attachment, using the Image Macro, either by navigating to the file location or dropping the file, I get the following error message:

Could not upload the file to Confluence. The server may be unavailable.

This does not occur when I originally upload the attachment (version 1). To upload a new version of the attachment, I have to either completely remove the attachment or go to Tools > Attachment and then "Lock to Edit" the attachment.

In previous versions of Confluence, I was able to overwrite existing versions via the in-text editing. Is this no longer the case or is this a bug?

2 answers

1 accepted

0 votes
Answer accepted
Jenn Leaver December 3, 2013

Scott, from the wonderful Arsenale support team, answered my question awhile back. I'd forgotten to post it.

The real problem was the vague error message, not the functionality provided by the Arsenale Lockpoint add-on.

"Jenn Leaver, you mentioned the presence of the "Lock to Edit" link, so it seems that you have our Arsenale Lockpoint add-on installed.

The symptoms you describe are related to a known bug in Confluence (CONF-21709 and alsoCONF-28564), which causes minor problems when used in conjunction with Lockpoint.

When you are uploading the file, Lockpoint is trying to tell you "you must lock the file before you can upload it", but Confluence eats the specific error message that Lockpoint provides (due to the bugs above) and instead you just get the generic "the server may be unavailable" message, which is obviously not terribly helpful.

There is currently no solution to the vague error message problem, although you can watch the above CONF-21709 and CONF-28564 issues if you want to be kept abreast of Atlassian's progress.

However, there is also a configuration change you can make in Lockpoint to ease the pain: if you go to Toolgear->Confluence Admin->Arsenale Lockpoint, you can enable the "Permit unlocked attachments to be modified without requiring a lock" setting.

This should allow your users to upload files (including from within the editor) without having to lock them first, so long as no one else has the file locked in the first place.

I hope this helps! If you have any other questions, feel free to send your contact information toArsenale Support so we can help you out directly.

Scott @ Arsenale"

0 votes
StevenA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 31, 2013

Hi Jenn,

Refer to this bug report, the time out for the upload process is 12 seconds. If expired, then, the above error message is displayed. When you replace a new version of an attachment image, Confluence would delete the old version and upload a new one. So, if your server is slow response, then it would be time out and the errors is displayed.

We suggest that you can follow below steps to fix:

1. Stop your Confluence.

2. Remove all files located under <Confluence Installation Directory>/work/ folder (Not the parent work folder). Finally, restart your Confluence.

Regards

Steven

Jenn Leaver October 31, 2013

Hi Steven -

Thanks for your reply. Unfortunately, I don't think the bug you referenced captures my situation.

I can upload the attachments without any issues. These are small attachments (.png files that are around 32kb). It's when I attempt to upload a new version of the attachment that I run in to issues.

Additionally, the bug you referenced specifies that only the "Insert Image" option fails, while both the "Insert Image" and "Drag and Drop" options fail in my scenario. I can only upload a new version of an attachment if either the original attachment is deleted or if I "Lock to edit" the attachment.

I can open a ticket for this - I just wanted to make sure before I did that this behavior wasn't a recent "enhancement" that I was unaware of.

Thanks,
Jenn

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events