Sync fails after bulk repair: Cannot change attachment linkMode (400) — migrated ZotFile-style linke

Guillermo Nicora

I’m using Zotero 9.0 (Linux, 64-bit) with a personal library, syncing both metadata and files to Zotero Storage (paid plan, ~60 GB).

Many years ago I used ZotFile (or a similar setup) so attachments were linked files with paths like attachments:SomeFile.pdf. After a mishap, the PDFs were no longer where Zotero expected them, but I still have a full backup of the PDFs with the same filenames as in the broken attachments:… paths.

To recover locally, I wrote a small script that, for each broken attachment row in zotero.sqlite (linkMode = 2, path starting with attachments:):

Copies SomeFile.pdf from my backup folder into ~/Zotero/storage//SomeFile.pdf
Updates the row to linkMode = 0 and path = storage:SomeFile.pdf, and sets storageHash / storageModTime like normal stored attachments.
This works locally (PDFs open again), but when I try to sync, Zotero reports something like:

Error 400 for item YIC6WPD4 in My library:
ZoteroObjectUploadError: Cannot change attachment linkMode
Made no progress during upload -- stopping
YIC6WPD4 is one of the attachments I converted from linked to stored. I have automatic sync turned off for now while I finish the bulk repair.

Question: What is the recommended way to get the online library back in sync after many attachments were converted this way? I understand the server may still treat those attachment items as linked, and the API may not allow changing linkMode on the same object via sync.

I’d prefer not to lose years of citation keys / item keys if possible, but I need a clear strategy before I re-enable syncing (metadata + files).

Thanks for any guidance.

Guillermo Nicora

The folder name must be ~/Zotero/storage//SomeFile.pdf (not a doble /, the [itemkey]folder name instead ...storage/ and ?Somefile...)

adamsmith

Revert any changes you made to the sqlite directly (i.e., restore from a previous backup). That's a recipe for disaster all around and Zotero has various scripting options (API, local JavaScript API), that allow you to handle this without touching the sqlite -- very likely you can even fix it just with Zutilo or even with Zotero's built in base directory functionality

tim820

You mention that your linked file paths started with an "attachments:" prefix. That means you had a Linked Attachment Base Directory (LABD) entry in Zotero settings (on one or more computers); either continuously from some point in the past, or at least at one point in the past (otherwise the linked file paths would be stored as explicit direct paths to each PDF, the default when there is no LABD setting - the stock Zotero setup). The "attachments:" prefix basically tells Zotero to "insert LABD here when trying to open this PDF".

As such, the first way to investigate fixing a situation where Zotero says it can't find linked PDFs (when you try to open one) is to look at changing the LABD. The clue is often in where the Zotero error message says it is *looking* for PDFs (ie the current LABD setting on that computer) versus where they actually *are* on that computer. Alternatively, if the error message doesn't tell you where Zotero is looking for a PDF, it usually means no LABD is set on that computer (but is/was set on another computer).

Fixing the problem is often just a case of setting the right LABD on each computer you use. Or simply moving PDFs (in your OS) to where the LABD on each computer is telling Zotero to look for them. It is however possible for a user to have created more complex problems with linked file locations, which will require more complex solutions.