Upgrade StorageZotero 7 sync error: Unknown field “lastRead” after accidental Zotero 9 upgrade and downgrade
Hi,
I’m using Zotero 7.0.32 ARM64 on macOS.
Zotero was accidentally auto-updated to Zotero 9.0.2 in May 2026. Many of my Zotero-7-specific plugins stopped working, so the person who configured my setup downgraded Zotero back to version 7 and disabled automatic application updates.
I now receive this sync warning:
“Some data in My Library could not be downloaded. It may have been saved with a newer version of Zotero.”
The underlying error is:
Invalid data error for item Z43AUCWH:
Unknown field 'lastRead'
Debug ID:
D1642235260
The affected object is:
- Item key: Z43AUCWH
- Item type: PDF attachment
- Parent item key: NB2VSNQC
- Parent title: The culture of curating and the curating of culture(s)
The PDF itself exists locally and opens normally. WebDAV file syncing through InfiniCLOUD is also working — Zotero has successfully uploaded .zip and .prop files.
A read-only inspection of the local database found:
- Z43AUCWH is the only attachment with a non-null itemAttachments.lastRead value.
- lastRead = 1779695957
- The object remains in syncQueue and has been retried repeatedly.
- The local upgrade log shows that Zotero 9.0.2 upgraded the profile schema and added the itemAttachments.lastRead column.
This therefore appears to have happened after the profile was briefly used with Zotero 9 and then downgraded to Zotero 7.
There was also a separate dateModified formatting problem affecting five notes, caused by an external SQLite script. That issue has already been repaired and no longer appears during syncing.
Because my current plugin setup still requires Zotero 7, is there a supported and safe way to remove or normalize the lastRead property for this single server-side object, without deleting/recreating the attachment or replacing the entire online library?
I understand that remaining on Zotero 7 is not ideal, but I need to do so temporarily until the plugins in this configured environment can be migrated safely.
Thank you.
I’m using Zotero 7.0.32 ARM64 on macOS.
Zotero was accidentally auto-updated to Zotero 9.0.2 in May 2026. Many of my Zotero-7-specific plugins stopped working, so the person who configured my setup downgraded Zotero back to version 7 and disabled automatic application updates.
I now receive this sync warning:
“Some data in My Library could not be downloaded. It may have been saved with a newer version of Zotero.”
The underlying error is:
Invalid data error for item Z43AUCWH:
Unknown field 'lastRead'
Debug ID:
D1642235260
The affected object is:
- Item key: Z43AUCWH
- Item type: PDF attachment
- Parent item key: NB2VSNQC
- Parent title: The culture of curating and the curating of culture(s)
The PDF itself exists locally and opens normally. WebDAV file syncing through InfiniCLOUD is also working — Zotero has successfully uploaded .zip and .prop files.
A read-only inspection of the local database found:
- Z43AUCWH is the only attachment with a non-null itemAttachments.lastRead value.
- lastRead = 1779695957
- The object remains in syncQueue and has been retried repeatedly.
- The local upgrade log shows that Zotero 9.0.2 upgraded the profile schema and added the itemAttachments.lastRead column.
This therefore appears to have happened after the profile was briefly used with Zotero 9 and then downgraded to Zotero 7.
There was also a separate dateModified formatting problem affecting five notes, caused by an external SQLite script. That issue has already been repaired and no longer appears during syncing.
Because my current plugin setup still requires Zotero 7, is there a supported and safe way to remove or normalize the lastRead property for this single server-side object, without deleting/recreating the attachment or replacing the entire online library?
I understand that remaining on Zotero 7 is not ideal, but I need to do so temporarily until the plugins in this configured environment can be migrated safely.
Thank you.
-
dstillman Zotero TeamWe can't support old versions, particularly after a downgrade, but this should now be fixed.