At a glance I'm not sure exactly what is causing these errors without more information. I can however offer a few starting suggestions.
First, it would be helpful to know more about your installation, such as:
- What is the full AtoM version number listed in Admin > Settings > Global at the top of the page?
- Have you recently upgraded?
- Did you follow the recommended installation instructions for your version? If no, what changes have you made (in operating system, PHP version, database, webserver, etc)?
- Was this record created via the user interface, or imported?
- If created via the user interface, was any of the text copied from an external source such as a Word document?
- If created via import, did you use Microsoft Excel to prepare your CSV?
I ask the upgrade question because sometimes key steps are skipped in the upgrade process, meaning that the internal database schema does not match the actual database being loaded, which can lead to strange outcomes with similar error messages to those I saw. In most cases, the missed step is that the database is not dropped and then recreated before the sqldump is loaded (step 4 in this section of the 2.6 upgrade documentation). If you think this is the case, it's generally best to repeat the upgrade process and make sure you don't miss these key steps. See for example the suggestions in this thread:
Regarding the questions as to how the record was created, I noticed that other descriptions had no issue exporting as EAD, suggesting that there's something unexpected in the metadata of this record set causing problems. The most common of these is non-UTF-8 characters that causes the export process to fail - a common issue when text is sourced from Microsoft products, which typically use their own custom character encoding instead of the de facto web standard of UTF-8, which AtoM expects.
In the biographical history of the related authority record for example, I can see what appear to be Microsoft's custom "curly quotes" that slant in a particular direction around the text. If you copy this character into the navigation bar of a separate browser tab and then manually enter a double quote character next to it, you can see the difference. It's possible something like this is making the export break. For more information, see:
There's also more specific information on this in the 2.7 documentation, as the 2.7 release will include a new option to validate a CSV prior to or during import and check for common errors. On UTF-8 issues, see:
We often recommend that AtoM users consider downloading LibreOffice Calc as an open source alternative to Microsoft Excel, as it defaults to UTF-8 and provides options to check and set the character encoding, separators, and other elements before opening any CSV.
As an aside, I doubt this is the cause of the error, but it may lead to related performance issues on large operations: I noticed that this particular authority record, the Catholic Women's League (CWL), is manually linked as the creator in many different levels of the same fonds (Catholic Women's League - East Anglia Branch). AtoM has an inheritance system in place for both creators and repository names, meaning that if the creator is the same in a child-level description as its parent, then AtoM will automatically inherit the creator name at the child level, and you don't need to manually enter the creator there. In fact, doing so means there are many more unnecessary relationships in the database that can cause timeouts when attempting long running operations - including exports. The inheritance system is also meant to align with the ICA's general principles of description (namely, add information at the highest relevant level, and do not repeat information unnecessarily at lower levels) - while you can definitely add a different creator name at lower levels where needed (i.e. when the creator is actually different), if the creator is the same at lower levels then it's generally better to leave it blank during record creation - the inheritance will include the creator name at lower levels in the view pages of the related descriptions.
Fortunately, there's a command-line task that you can run that will automatically check parent descriptions and remove any unnecessary manual links to the same creator in child descriptions when found. See:
I would try running this task, and then manually fixing the quotation marks used in the authority record History field of the CWL, and see if that has any effect on the export. Check the archival unit itself for any other instances of potential non-UTF-8 characters as well.
Finally, it's also possible that there's some data corruption that is causing the problem. A good first step is to run some common command-line maintenance tasks to ensure that the nested set is properly built, all records have slugs, the application cache is cleared, and the search index is up to date. See:
You can also run the following query to check for other forms of data corruption - there are some suggested remediation steps on the same page, depending on what you find:
If none of the above helps to resolve the issue, then hopefully the additional information you provide about your installation and archival unit in question will allow us to provide further suggestions. Let us know what you find!