I will consult my team and see if we can come up with further suggestions. Given the example provided, I'm now not surprised there is no thumbnail (more on this in a moment), but the fact that you can't get to the digital object edit page suggests something else is going on as well.
However, this does not meet the documented requirements that AtoM expects from remote digital objects to be able to successfully link the content and generate a derivative. For AtoM to be able to do so, the URI must:
- Be available on the public web - no passwords, VPNs, confirmation screens, etc. should be required or else AtoM will not be able to fetch the digital object
- Use HTTP or HTTPS - local share drive links, FTP or SFTP links, etc will not work
- End in the file extension of the digital object (e.g. .jpg, etc). That is, the URI needs to link directly to the target digital object, and not to a landing page
It is this third criteria that your URI appears to be missing. When I follow the link, I am taken to a landing page for a compound digital object made up of individual scans, with separate JPGs for the first 40 pages showing on page 1 of this landing page.
To create a derivative, AtoM needs to be able to fetch a copy of the target digital object, store it locally in a temporary location, and then use that to create the reference display copy and thumbnail via tools like imagemagick. In this case, there are 40+ choices on the page. AtoM's link digital object via URI functionality doesn't have the capacity to semantically parse the contents of the provided URI, find a digital object, and then follow that link - it's very simple, and if the provided URI doesn't point directly to the target digital object, then the derivative generation will fail.
Instead, you would need a URI that points to the target itself - for example, if the PDF option on the landing page were pre-generated rather than created by the site on the fly, then linking to the PDF version might work, since it's possible to get to a URI that ends in .pdf:
Alternatively (although I doubt this would be desirable for a multi-page digital object), it appears possible to get to suitable URIs for the individual pages, like this one:
This third criteria is flagged in the related documentation in an "Important" admonition below step 5 of the "Link a single digital object" instructions, in this section:
I will review our documentation and consider how to make the criteria for remote digital objects more explicit for 2.7.
It's possible that in the past, someone uploaded their own custom derivatives - e.g. a screenshot of the target landing page, or of the first page of the document. However, running the derivative regeneration task would mean that any previous custom manual derivative uploads would be overwritten by AtoM's attempt to regenerate the derivatives. So: if it was working before, it may be because the old site still has custom derivatives in place, but your upgrade process removed those. My theory is then that AtoM is trying to access the JPG derivative that was previously there, but it no longer is - hence the 404 in the error logs.
Manually adding custom image derivatives to external digital object URLs that don't meet the linking criteria is a workaround I have seen some community members use before - for example, linking to a YouTube video would have the same problems as what you are experiencing (YouTube purposefully obfuscates access to the URL pointing directly to the MP4 to prevent unauthorized downloads, so a YouTube link doesn't work in AtoM in the same way), but I've seen users add video links and then provide their own screenshots of the video to use as the reference copy and thumbnail. There is a tradeoff to this approach however - the media type of the digital object will be wrong if you want your thumbnail to show, which can impact search and browse:
- If you manually set the media type to "video" then AtoM will try to display the media player on the description view page - meaning your custom thumbnail won't show, and the video player will be empty, and only the authenticated users will see a "Download" link that will actually link out to the YouTube page
- To get the custom derivatives to show, you need to set the media type to "Image" (or if I recall correctly, "Other" will work too) - but then when using the Media Type facet in search and browse, your description will not be included in results limited to "video."
- Public users will also need to either use the URI in the digital object metadata section (which some public users will not see), or else the "anonymous" user group (i.e. public users) need to be given "View master" permissions so they can click through the derivatives to the source link
So: yes, in this particular case, it's possible that running the derivative regeneration as part of your upgrade process has caused this issue.
If you were happy with how things were working previously and you still have your 2.5 installation and backup data, then one thing you could try now would be replacing the current 2.6 uploads directory with a fresh copy from your 2.5 installation, and not running the derivative regeneration task this time. You would still want to run several other maintenance tasks after replacing it - I would clear the application cache, restart PHP-FPM, and possibly reindex the site as well to see if the replacement worked.
In the meantime, I will see if our team has any other suggestions.