Hi All,

I just want to provide an update on our work to provide a fix for existing broken pages, and address the comments above.

Unknown Attachment App

Firstly, we are tracking our work to resolve the issue for pages that are already broken at CONFSERVER-63615: Provide workaround for fixing broken unknown attachment placeholder in storage format. We have just provided an update on that issue detailing an app that is available to resolve some of the broken attachments. I'd encourage you to carefully review the documentation for the app prior to installing it.

If you'd prefer to go straight to the documentation (which includes a link to the app), you can head directly to Unknown attachment error in Confluence Server and Data Center 7.12 and earlier

Understanding the Fix

With regards to the conversation about the efficacy of this fix above involving saikrishna.patel, dbd206fd02ab, and ggautam I would like to explain some things to help understand the fix.

Confluence uses a system called Synchrony to allow collaborative editing of pages by multiple users. When a user edits a page, Confluence (creates if necessary, then) passes a draft to Synchrony which handles the editing of the page. Changes made in Synchrony are sent back to Confluence on a timer (to make sure we don't lose data), and when the editor is closed or the page is published. The issue being tracked here occurs when Confluence passing data back and forwards with Synchrony. This fix stops newly created drafts from being impacted by this issue.

The problem then is that there can be drafts that were created prior to this implementation of this fix that are still impacted. This would give the appearance of the bug appearing for the first time, but in reality the bug has already impacted the page, it's just not visible yet. This is, unfortunately, expected behaviour with this fix, but it is something we can help repair. In cases where this issue is becoming visible for the first time, the app mentioned above will help you resolve this issue.

Given the impact this bug was having on our customers, we split the work of fixing the bug, and repairing impacted pages into two streams to try and get a fix out as soon as possible. This is why the solution to repair impacted pages is not part of this fix and not built into Confluence (yet).

At this time, we understand that the issue is fixed. Our testing has reflected this, and we've been receiving confirmation from impacted customers that they're no longer seeing new occurrences of this issue.

If you are continuing to see a related problem, please open a ticket with support at https://support.atlassian.com and we'll help you look into the issue.

Other Question

To address the other query I can see
58846cf653c8 - There is no fix available for Confluence 7.9.x, however the app that attempts to repair impacted pages can be installed to mitigate the issue (it will try and repair the pages as they break). Even with this app, I would recommend upgrade to Confluence 7.12.2 (the fix is in 7.12.1) to receive the fix.

Final Notes

The development team and I want to extend our thanks for all the data and troubleshooting information that was provided by various people on this ticket and in related support tickets.

Thank you also for your patience and understanding as we worked through this one. We know these issues have a massive impact on you and your users, and we've been working hard on these issues to get them fixed.

Happy editing

Regards,
James Ponting
Premier Support Engineer

Hi saikrishna.patel

> we have tested a page which does not have any broken links or attachments, when we tried to edit the page in Confluence 7.4.9 we saw again "Unknown attachments" error like we used to see previously.

GG - I remember the pages you shown earlier and would like to explain why. Its because of already broken draft and not a new breakage.
Unfortunately when an attachment event was not sent to Synchrony, drafts first get broken as they are auto-saved. You can see broken attachment on the pages where drafts are already broken. I would recommend you to try the replication steps I mentioned in above comment to be sure that the pages are not broken anymore.

Please watch CONFSERVER-63615 for the workaround issue to fix broken content.

Thanks, 
Ganesh

Hi Ganesh,

Thanks for the update. After upgrading confluence from  on 7.4.7 to 7.4.9on  June 4th we have tested a page which doesnot have any broken links or attachments. Before editing the page in confluence 7.4.9 we didnt saw any "Unknow Attachment" error in confluence page. When we tried to edit the page in Confluence 7.4.9 we saw again "Unknown attachments" error like we used to see previously. We did updated the page and in updated page we see the same issue/error again.

Said so even in 7.4.9, fix for this issue didnt stopped for new occurrences of broken pages and attachments.

Thanks & Regards,

Sai

Hi Saikrishna, Daniel, Trevor

Thanks for reaching out.

I would like to highlight that any page whose draft is already broken is not fixed by this issue's fix. The fix for this issue stops new occurrences of broken pages and attachments.

Since this bug used to break the storage format in page entity and draft content themselves, you might still see already broken pages as broken even after the upgrade till the time the workaround for broken pages is put in place.

Please track CONFSERVER-63615 for incoming workaround which will help you in fixing existing broken pages(please see description of this ticket for more info on this) in your installation.

dbd206fd02ab, Yes we confirm that the issue was partially reproducible with 7.4.7 and all new tests for unknown attachment(for unknown placeholder) in our suites pass with 7.4.9.
We have tests in our system which execute the replication steps in many flavours and they pass after the current fix. I would recommend to perform same sanity in your system. Following steps can help you with it: 

1. Ensure Collaborative Editing is switched on.
2. Create a page with this storage format.

   <p><ac:image ac:height="250"><ri:attachment ri:filename="test.jpg"/></ac:image></p>
   

1. The page displays "Unknown attachment".
2. Via '...' > 'Attachments', just insert an attachment 'test.jpg' into the page. You'll see that the page now contains 1 attachment, which is 'test.jpg'.
3. View the page you first created and the image is now there.
4. Edit the page. The image should be there.

Thanks,

Ganesh

We have this bug in our 7.9.1 installation. I can't tell – did the work in this ticket address the 7.9.x series?

We were just in the process of updating. This is very disappointing.
We will carefully check whether this bug is actually fixed for us or not with 7.4.9.
From the way things look these days, worst case scenario is that it is not fixed, and we get some other issues with 7.4.9 compared to 7.4.7....

Atlassian, are you able to reproduce the issue on your end with 7.4.7 to confirm that it is actually fixed in 7.4.9?

Hi Team,

We upgraded confluence to 7.4.9 from 7.4.7 and able to reproduce the issue again for some pages. Bug still exists in 7.4.9.

Excellent. Thanks for the update.

A fix for this issue is available to Server and Data Center customers in Confluence 7.4.9
Upgrade now or check out the Release Notes to see what other issues are resolved.

Hi All,

Updates as promised.

We've just begun the testing process leading into the release of Confluence 7.4.9. As always, we can't commit to time frames, but assuming we don't find any additional issues, I would hope to see the release some time this week. This hope is obviously reliant upon all of our testing passing without problems. If we find problems, we're going to have to address them before we can release. I just want to let you know things are progressing and that hopefully we can release will be soon.

As always, please review the release notes for Confluence 7.4.9 when they become available.

dbd206fd02ab - No worries

e6907d9111f9 - There is not. Assuming you're already on Confluence 7.4.6, I would recommend targeting Confluence 7.4.9 when it releases.

As always, I'll let you know as new information becomes available.

Thanks,
James Ponting
Premier Support Engineer

James,

Is there a full fix for version for 7.4.6?

Hi James,

Got it. Thanks for the update.

Cheers,
Daniel

Hi All,

We now have Confluence 7.11.3 and 7.12.1 out with the fix. We're continue to work on Confluence 7.4.9, and I will provide an update as soon as we have information on that release.

dbd206fd02ab - Not at this time. We'll let you know as soon as we do.

admin1854195196 - This release only stops new occurrences of the bug. We're working on a seperate line of work to fix pages that are already impacted by this issue. That work is being tracked on CONFSERVER-63615: Provide workaround for fixing broken unknown attachment placeholder in storage format. Can you please confirm if you're seeing new occurrences of the bug, or if it's previously affected pages still showing the issue? We are expecting pages that were previously affected by this issue to still be effected.

If anyone has installed the updated version of Confluence, and is still able to reproduce the issue, please open a support ticket at https://support.atlassian.com and we'll begin looking into the issue.

As it stands, we believe the issue is resolved, though we will continue to monitor responses here and on our support platform for any hint otherwise.

Thanks,
James Ponting
Premier Support Engineer

Hi

yesterday i updated to v7.12.1 and the problem still exists with previously created pages.

@james only on previously created pages, no new occurrences so far.

That's great. Do you know the timeline for a fix for version 7.4.9?

A fix for this issue is available to Server and Data Center customers in Confluence 7.12.1
Upgrade now or check out the Release Notes to see what other issues are resolved.

Hi All,

Just providing some updates.

f539b529cd9d - No worries at all. I understood what you meant, I just wanted to make sure it was clear for others without the context we had. We definitely do appreciate such suggestions. Apologies for the belated reply, just trying to avoid spamming everyone by replying to individual comments. I'm going to touch up your previous bounce and add a note to it to see your most recent comment.

76f40437545f - We can't provide you with a date currently. We're continuing to work on Confluence 7.4.9 including multiple high priority fixes, though I understand there is only one outstanding item at this time. Once that item is resolved, we will finalise testing and provide the release. We're trying to walk that fine line of getting fixes out rapidly, and not introducing new issues to our Long Term Support releases. Once I have a release date, I'll include that information for you all to begin planning.

In the meantime, as Confluence 7.11.3 was ready to be shipped so we have released it with the fix for anyone who is in a position to upgrade to it. We're continuing to work on getting the other noted Fixed Versions released, and will continue to provide updates as they're available.

EDIT - I've also re-opened the ticket as it was erroneously marked as closed by our automation. It will not be considered closed until all the fixed versions are released. Apologies for the confusion.

Thanks,
James Ponting
Premier Support Engineer

I don't know if you noticed, 7.4.9 is still not available. Can you give us a date?

A fix for this issue is available to Server and Data Center customers in Confluence 7.11.3
Upgrade now or check out the Release Notes to see what other issues are resolved.

Hi James,

thanks for your feedback. Me referring to "this issue" might be confusing. We get sent plenty pages with "Unknown Attachments" where the reasoning might not always be the bug described in this issue. The query might be worth checking out if you aren't certain the bugged attachment is a result of this issue.

Best regards,

Alexander Puhla

Hey f539b529cd9d,

That's query will certainly work in the scenario you've described.

Unfortunately the issue in this ticket is different to the one you've encountered. That being the case, the above query will not work for the users affected by this bug.

Thank you for sharing your findings though, we always appreciate work arounds identified by our customers

Thanks,
James Ponting
Premier Support Engineer

We found a different approach to resolve this issue for two of our newest occurances. It seemed like the pages were referencing an attachment from a deleted page. We located the page by the following query:

SELECT t2.title AS Title,
       t2.contentid AS PageId,
       t3.spacename AS Spacename,
       t3.spacekey AS Spacekey
FROM
    (SELECT *
     FROM content
     WHERE CONTENTTYPE = 'ATTACHMENT'
         AND title LIKE '%ATTACHMENT-NAME%') t1
JOIN
    (SELECT *
     FROM content
     WHERE CONTENTTYPE = 'PAGE') t2 ON (t1.pageid = t2.contentid)
JOIN spaces t3 ON (t2.spaceid = t3.spaceid)

We restored the deleted page from the bin, downloaded the attachments and added them to the page with the broken attachments. You might wanna give it a try, if the other workarounds don't work for you.

Atlassian Note: f539b529cd9d provides some additional context on this query below - jponting

Hi All,

Just reply to a couple of comments

application.support2 & saikrishna.patel - We don't currently have a release date to share. We're actively working on these releases as both have critical bug fixes in them (including this) that we need to make sure we get to you all. Getting these fixes out to you all is our top priority. When I have more information, I'll let you know.

2b0415d20a38 - We're currently working on methods to automate fixing this issue. We're tracking that work at CONFSERVER-63615: Provide workaround for fixing broken unknown attachment placeholder in storage format. Please add yourself as a watcher on that issue to receive updates as we have them.

brudy - Assuming that behaviour is caused by this bug, then no. This fix will only stop future occurrences. For more information our work to fix existing occurrences of the bug, please see the above link.

As I get new information that is relevant to this issue and those of you impacted by it, I'll continue to provide it here.

Thanks,
James Ponting
Premier Support Engineer

Will this also fix the bug when I have an image successfully attached to a page that worked fine before, only to go back to it later and get the "unknown attachment" error?  

Are we expected to scan all our confluence pages and use workarounds to restore images that were perfectly fine before?

When you will release 7.4.9?

When will you finally release 7.11.3?

wow,me too.
 

We got this bug as well ! in many pages

This is shameful - you should be ashamed, Atlassian. The workarounds do not work for me. Many hours lost. Why am I not using a freeware Wiki, why are we paying for this?

Totally agree with Aleksei. This bug should be fixed ASAP and once for all. It's totally unacceptable to have a bug opened with the Highest priority for almost 3 years without any permanent solution. This approach is totally unprofessional and because of this bug, our documentation is devalued. It means we can not provide our customers with all comprehensive information and features. There are so many issues with Confluence that we are really reconsidering the usage of Atlassian products in the future. 

Hi All,

Just providing an additional update on this one.

We have a fix targeting Confluence 7.4.9 and Confluence 7.11.3, both of which will release in coming days.

Unfortunately we were unable to get the fix into Confluence 7.12.0 prior to release, so we're looking at Confluence 7.12.1 as a candidate on the 7.12 branch. This should result in a fix in the next LTS release which should be Confluence 7.13.0.

To be clear, the fix being merged should stop new occurrences of this bug appearing, however it will not fix pages already affected by this issue.

With that fix in flight and being released to customers, we're now tracking work on correcting already impacted pages at CONFSERVER-63615: Provide workaround for fixing broken pages/shared-drafts because of "Unknown Attachments".

To be clear, whilst the goal is to have some option that just corrects the issue for impacted customers, there may be some cases wherein automatic correction is not possible, and manual intervention may be required. Hopefully we can find a one click solution, but I want to set expectations early and clearly.

Thank you again for your continued patience with this issue.

Thanks,
James Ponting
Premier Support Engineer

Confluence 7.4.7 LTS does not fix it either. We can still see it sporadically appearing on 2 independant Confluence Server instances we operate (both 7.4.7 LTS).

In terms of troubleshooting the only way that helps is:

• revert the page to the last known good version
• re-do all editing steps of the last page update resulting in the faulty page using the pairwise comparision in the history as template

Atlassian Confluence 7.10.0 still has this issue and we noticed a page where the edit recently happened (on Mar 02, 2021).

Reach out if we can help with logs/exports ...

In our organization this problem has arisen after editing pages in which the images already existed. In some cases, they have become 'Unknown attachment'.

We are using Confluence 7.4.5 LTS.

Suggested workaround option 1 is not working

This issue is reported in 7.9.0 version. Performed the below steps and was able to see all my PNG images back.

Option 2 - For Confluence 6.9 and up

1. Open the editor for the affected page
2. Click on the ellipsis button on the bottom right corner of the screen (besides the Close button)
3. Click on revert back to the last published version
4. Check if the attachment appears on the editor now

Hi, same here for Confluence 7.7.4

This reported on 7.8.1 as well.

This was reported by my colleagues,too. We use 

Confluence 7.4.7

Affects 7.8.3 too

Hello,

we are also affected by the bug with almost 500 pages of about 90 areas.

And have a ticket open with Atlassian CSP-289338, but here we are not offered any real help either.
We are supposed to rework all pages by hand to have working pages again. That is an extremely big effort to fix them all manually with the workaround.

The workaround when rolling back page versions is nothing but a workaround, because here I have to maintain the content from the latest page version as well, otherwise I will have an even bigger data loss.
The alternative to rollback page version is to reattach the attachments. But even that is not goal oriented, because often the images don't even exist to reattach them.

So I expect that Atlassian must support us in some way.

I have checked the first two pages from the list of affected pages.
But on the first page, the image is already showing as Unknown Attachment in the first version.
So nothing can be restored here, which is totally unacceptable.

On the second page I found a version of the page where the images are still there correctly.
But here I have to find all the data from the last version and then paste it into the restored version.

For each affected page, it takes about 5-10 minutes to restore the entire site, and with 449 pages, that's one to two weeks of work for one person.

Atlassian should also be aware of this and be willing to assist or compensate us in some way.
Add to that the loss of data for some pages that cannot be recovered.

Can you develop a "Migrate two page versions to one version" app that allows the user to select which version the part can be taken from after each paragraph and for tables each cell.

This would be a solution to really help everyone who has this error. Since would still have to edit each page by hand, but that would significantly reduce the processing time.

Also, I've already reported via comment and in our other ticket that we're affected with version 7.5.1, but again, that's not being reasonably updated in this ticket. For us is also not clear until when a fix for the bug is available, that this can not happen again with pages.

We from ebm-papst see here Atlassian quite clearly in the duty to do more.

Yours sincerely,
Henning

This also affects version 7.8.1

We are also affected by the problem on some pages in different spaces.
In Confluence version 7.5.1

Nice. Thanks for the info, Amanda!

Daniel, we tried option 3 and it didn't work. It didn't break anything - It just didn't fix the problem. Not sure if it breaks stuff for some folks and not others though. If you decide to try it, I'd recommend telling your creators not to touch their content while you toggle it. While Collaborative Editing is off, all of the drafts that were created while it was turned on will be invisible and it could cause people to freak out thinking their drafts are all gone. Also, if anybody clicks edit on a document where there was already a draft in collaborative mode, then their drafted edits will replace whatever was created in collaborative editing mode, so you could lose content in that way.

Please note that this is really starting to become an acute issue for us now. We are inclined to try "Option 3" as a workaround but it says "never to use this workaround", despite it seeming compellingly simple. What would be the consequence of this simple toggle operation of the Collaborative Editing mode, if I may ask?
Is there another bug that would get kicked loose by this?

Hi msaxby,

I am not sure if this also needs to be cleared, but "Fixed in Long Term Support Release/s:" is still showing as "Download 7.4"

Thanks for your continued attention.

Rick

Hi Matthew,

We are also experiencing this issue and are using version 7.4.1. It's quite a mean one which affects our capability to work collaboratively.
Do you have a rough idea when your team might be able to provide a fix?

Thanks,
Daniel

Thanks for flagging that gonchik, I have removed the fix versions. 

Hi All,

After having the team investigate we can confirm that this issue is still happening. I have gone ahead and reopened the issue and it is currently a top priority for our team to resolve. We are very sorry to have misled so many of you by closing it. This is a complex bug that surfaces in many ways. If you are experiencing this issue and can replicate it in your environment, please get in contact with our support team at: https://support.atlassian.com/contact/.  Please mention my comment on this issue so support can reach out directly to me and my team. 

Regards,

Matthew

Product Manager | Confluence Server & DC

If you on confluence >= 7.4.6, and still have "unknown attachments", maybe you are affected by this bug: https://jira.atlassian.com/browse/CONFSERVER-60526

We also had the problem, updated our instance to 7.4.6 and the issue still persists. So we contacted Atlassian support and it turned out, that we are now affected by the issue linked above. 
If you want to check, witch bug your page is affected, there is an easy way: 

1. Navigate to the affected page
2. Click on "View Storage Format"
3. If you can't find "unknown attachment" in the code, you are affected by the bug linked above. 

So in the new variant mentioned above, the workaround is to search for*<ri:content-entity ri:content-id="..."/> inside <ri:attachment>*  and remove it. Maybe it is possible to automate it somehow.

Hi, we do have the same problem with 7.4.5. The problem just appears sometimes on some random pages. The good thing is, that the attachments are still there, just not linked, so in most cases we can fix it manually.

I'm kinda afraid of the impact we did not see right now and I'm not clicking through all the pages we have...

We are also still waiting for a fix in LTS version. Please Atlassian fix this bug as soon as possible!

Agree, we are using Confluence for our development documentation and certification. With this bug the software is totally useless.

No professional appearance !!!
Here it is suggested that the problem has been fixed, which is not the case. This is how you lose your customers.

Yes, it is still happening with 7.4.6.

still happening with 7.4.6. This is really annoying and causes a lot of frustration!

same problem here. current version 7.10.0, we upgraded form a version without the issue. problem started after the upgrade

Issue persists on 7.11.0 - we updated from 7.4.5 with already corrupted pages.

@atlassian: Do we need to specifically upgrade from any given affected version to one of the issue resolved versions?

We'll now update to 7.11 just to be safe - even it's not an LTS version. 

@Tobias Schaer: It is fixed in 7.4.6 - and this is an LTS version. But this problem occures stil in that version!

@All:

We have written ourselves a tool with which we can correct the pages. Unfortunately, this has a few limitations and for us the correction works quite well.

But since the error is not fixed yet, the error occurs again and again!

The tool downloads the content of the page via REST, searches within the content for attachments / images, extracts the filenames from them, then replaces the image with a placeholder like XXXFILENAMEXXX and saves the page in a new version. It also downloads the attachments temporarily.

After that I upload the images again under a new name and then search the content of the page for XXX?????XXX and replace that again with the attachment plugin.

At the end I mark the page with a tag, so that the program does not have to go through the page twice.

This works 70% of the time, even with pages that are already broken. I then try to reconstruct the other 30% from the history. I check there how many images are on the current version and how many are on the previous one. If these are the same number of images, I hope that the order has remained the same and then correct the current page accordingly.

We have corrected over 10,000 pages with this. Took about 6 hours and basically we had 90 - 95% of the pages corrected with it. But since the error is still not corrected, all this brings quite little.

Support request has been created. Just wondering: Why hasn't this fix been applied to 7.4.7 as well? We don't want to move from an LTS to a non-LTS version.

Hi All,

I've been seeing an increasing number of customers reporting that they are still being affected by this issue. Firstly, we are really sorry about this and we want to make sure we get to the bottom of it. I am very keen to have our team investigate it further and would love your help. If you believe that:

1. You have upgraded to a version that contains the fix (see fix version list at the top of this bug report) and
2. you have attached a file to a page after you have performed the upgrade and found it is coming up as an "Unknown attachment"

Please get in contact with our support team at: https://support.atlassian.com/contact/.  Please mention my comment on this issue so support can reach out directly to me and my team. 

We really appreciate any help you can provide us in replicating how this issue still comes up so we can get to the bottom of it ASAP.

Regards,

Matthew

Product Manager | Confluence Server & DC

A fix for this issue is available to Server and Data Center customers in Confluence 7.6.3
Upgrade now or check out the Release Notes to see what other issues are resolved.

Is there a possibility to revert the link adjustment? We have updated to 7.4.6 and the issue has not been resolved. Even though the attachements are still linked, we cannot even delete and re-link them to the already uploaded images. 

The only workaround is now to upload the images altogether and add them to the page again on 7.4.6, which is tedious and not scaleable. Simply re-linking the attachment does not work, assuming this means your approach of re-assocciation. Please provide us with a real solution approach. As far as I can judge from the previous comments, we're not the only ones affected.

if you still have these problems, please raise a support ticket, so Atlassian will be aware of this. I don't think, they're actively tracking this ticket. 

In our Confluence LTS Version 7.4.6 a page is affected which was created after our update to the fixed version. So yes, the bug is not fixed yet.

Hi
This Bug still occurs in 7.4.6

Will there be a fix for the LTS Version 7.4 eventually? If no, in which Version is it fixed?

We still have this issue on Confluence 7.8.3 (Datacenter). Please fix this issue as our 5000 users are getting really grumpy now. We promised them that this issue will be fixed in the next upgrade (based on the information in this ticket) but the issue keeps reoccuring after every upgrade..

@Tom Penndorf : we run 7.8.4 Server and the issue is still occurring

Please update to 7.4.6, where the bug should be fixed. 

We still have this issue, we are on 7.4.5 and have newly create pages that have this issue...

We have updated to Version 7.7.3, we asume new pages won't get the Unknown Attachment Bug anymore but we got lots of "old" pages that are still facing this but!

The only "workaround" right now is to copy the affected pages for the whole space. 

The Problem is, all the links have to be changed too!

Seriously there should be some kind of agent or SQL statement to fix this problem. 

BTW: what happen when we run into this bug in a later version again, should everyone repair their page on their own again? 

We upgraded to Jira 7.4.6 on 07/Jan/2021 and reworked hundreds of pages by assigning pictures manually. When we now want to edit the 'repaired' pages the images are gone again: unknown attachment.

The bug is already been fixed in 7.4.6, so the error shouldn't occur anymore, when editing pages. However, already broken pages will not be repaired automatically. Atlassian says, it's not possible to automate this....

When this will be fixed for LTS version? 7.4.x

A large organization like ours only uses the LTS versions (7.4.6) and this is impacting our environment. 

Why you guys have LTS if a fix is never published as a priority? Doesn't make sense to have an LTS version then.....

Hello Hasnae

thanks for the information!

Fix in the sense of "after having 7.10.1, the issue will not reoccur but pages already facing the issue are still broken"?

Regards, B

A fix for this issue is available to Server and Data Center customers in Confluence 7.10.1
Upgrade now or check out the Release Notes to see what other issues are resolved.

Hi all,

We have this problem on more than 500 pages and have a total of over 2000 pages and we don't even know on which pages the problem could theoretically occur.

I have now done the following:

1. by REST I have downloaded the page content
2. by REST I have downloaded the attachments from the respective page
3. by REST I have uploaded all attachments again under a new name
4. then I manually searched for the attachment in the content

<ac:image ac:width=\"650\"><ri:attachment ri:filename=\"image2019-9-5_8-10-33.png\" /></ac:image>

and I replaced this line with for example "XXXXX_image2019-9-5_8-10-33_new.png_XXXXX".

5. by REST an update on the page --> Now there is no picture on the page anymore, but only XXXXX_image2019-9-5_8-10-33_new.png_XXXXXXX.

6. then i replaced XXXXX_image2019-9-5_8-10-33_new.png_XXXXX with <ac:image ac:width=\"650\"><ri:attachment ri:filename=\"image2019-9-5_8-10-33_new.png\" /></ac:image> and uploaded it again as a new version

7. delete the old filename as attachment by REST

After that the problem for this page was solved. This would now have to be automated as a program for all pages. But this is quite an effort. But I don't know if this would work for everyone.

This is really time-consuming, but I don't understand the statement that it does not work to correct the page. From my point of view it works, it is just a question of willpower.

This is still happening in v7.8.1

Hi, 

thank you for clarification.

Hi All,

As mentioned by philip.fyvie1113751497 and 5717f2a94c18 we have backported this bugfix to 7.4 and it is now available in 7.4.6. A few notes from our team:

1. This fix will only stop the issue from occurring in the future and will not repair situations where an attachment has been disassociated in the past. As mentioned in a previous comment, this bug results in Confluence losing the association of the editor reference to a file. For this reason, it isn't possible for us to safely automatically re-associate the editor reference to a specific file. However, the underlying file is still attached to the page and the only thing that has been lost is the specific editor association. The best way to fix this is for a subject matter expert of the page to re-associate the reference with the actual file.
2. The association of attachments to pages is complicated and we have made every effort to fix the issue for all situations where it might arise. If you are still running into issues after upgrading to 7.4.6 please get in contact with our support team at support.atlassian.com so we can investigate your specific situation.

Thank you for all those who have helped us in the investigation of this issue over the past months and for being patient as we backported this fix to 7.4. 

Cheers,

The Confluence Server/DC Team

Hi @Tobis. I was basically checking each day myself as well.  

Hi @Carl Liebich,

thanks for your information. 

Do you watch this? I don´t know how to get this information without looking every day on the release notes

FYI: I can see 7.4.6 has been released. 

https://confluence.atlassian.com/doc/issues-resolved-in-7-4-6-1031833497.html

We are waiting 7.4.6 release

we are also meet this issue, and we are upgrade our datacenter from 6.15.7 to 7.4.4(*LTS )   at 25/10 .*And all the issue attachment is upload to page before 25/10,  only we Click on revert back to the  published version before 25/10 Then the attachment appears on the editor.  

 So I think there most probably because of we upgrade datacenter to 7.4.4(LTS) then couse this issue.  

Pls kindly check it and found some way let us can got back the picture of attachment  without revert back to the  published version before 25/10,

Because if revert back to the  published version before 25/10  the page will miss many data.

When is the backport to 7.4 LTS stream likely to be made?

Maybe, you created an broken shared draft with the old version and after updating, you continued the broken draft and published it. 

I have a known affected page in our production Confluence instance as if you go to edit it, all of the attached show all images as "unknown attachment" in the preview.
I haven't been game to save it as there's 50+ images.

I've just gone through a dry run upgrade to the newest version of Confluence 7.9.0 and checked out this page and the problem still definitely exists - on editing the page, changing nothing and clicking save all images are now dead.
Reverting to a previous version did work and the images have all re-appeared - literally the version it was on 10 mins ago in the broken-on-preview state.

So this seems to be sort of fixed... but not completely.

Hello Matthew,
I think if Atlassian focuses only on fixing cases that occur on pages created AFTER the Confluence update, then this is not a real fix.
Because 99% of the content was created BEFORE the update.
And if these 99% degenerate bit by bit during editing (new page versions) then this doesn't help almost anyone.
Or should users create all pages again / copy?
But maybe I have misunderstood you here.

Hi All, We are currently investigating whether the fix that we have provided in 7.7.3 and 7.8+ has resolved the issue described in this bug report. We want to 100% verify this before we backport the fix to 7.4 (our most recent LTS). Thank you to everyone who has already upgraded and is helping us diagnose if the fix is working for them. If you have upgraded and are noticing this issue continue to occur on newly created pages (pages created after upgrade) then please get in contact with us by raising a support request at  https://support.atlassian.com/contact/ and mention this bug report. 

Regards,

Matthew | PM Confluence Server & Data Center

Adding to the list - we literally had this issue re-occur on Confluence Server 7.8.1 on a page that had probably more than 30 revisions. So it's still affecting:

• pages that are not working drafts (saved before)
• pages that were not edited by other users in collaboration (just 1 user working in this case)
• pages edited after updating to 7.8.1 (from 7.3 in our case).

Please implement a proper fix before rolling this out to any other (potentially hopeful) users.

see this comment: https://jira.atlassian.com/browse/CONFSERVER-55928?focusedCommentId=2561051&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2561051

TL;DR: November 2020

Like Rick, I also wonder if there is an expected release date for this fix to be included in 7.4 LTS.... thanks! If this is no longer the appropriate issue to follow please let us know if there is an issue we can follow that represents the task of including this fix in the 7.4 LTS... thanks!

Hi,

It's been over two months since this issue was marked as Resolved.
Do you have an expected release date scheduled for the LTS branch, please?

Thanks!
Rick

Is it possible that some users may have had broken drafts created before the upgrade to the fix version, and they then resumed editing on those and re-saved?

We have updated at the end of September to 7.7.3 an the problem still appears. 

Our only Workaround is to copy the affected page then the relation to the pictures comes back

Issue still exists in 7.4.4...