Syncing Zotero Attachments with Baidu Netdisk and AList

I used to use Nutstore to sync attachments for Zotero. Once it was set up, it mostly took care of itself, and switching between computers was seamless—until the free account’s transfer allowance started falling short.

According to the Nutstore Help Center, free accounts can upload 1 GB and download 3 GB per month. That’s fine for adding a few papers here and there, but once you’ve built up a lot of attachments, or need to download them again on another device, that allowance can quickly get tight.

A little while ago, I switched to a new MacBook Pro and quickly used up the month’s allowance while syncing attachments to it. When the next month came around, I burned through the new allowance on the very first day. I couldn’t keep going like that.

So I started looking for alternatives again. Nothing I found felt quite right, and I really didn’t want to pay for yet another service just to sync papers.

Then it occurred to me: I already had a Baidu Netdisk subscription and was already using AList. Could I connect the two and keep syncing Zotero through WebDAV?

What surprised me even more was that I hadn’t touched the Baidu Netdisk connection in AList for ages. Months, a year, maybe longer—I couldn’t remember exactly. Yet when I opened it again, it still worked. Since the connection was already there, I figured I might as well give it a try.

Why I Didn’t Go with a Plugin and a Synced Folder

Another common approach with Zotero is to move attachments into a dedicated folder, then sync that folder with a cloud storage client. The older ZotFile plugin and its current counterpart, ZotMoov, can help manage attachments this way. What you need here is folder syncing: simply backing up a copy of a file won’t automatically keep the copy on another computer up to date.

These setups usually turn attachments into “linked files”: Zotero remembers where the files are, while other software manages the files themselves. You need to set up folder syncing on both computers and make sure Zotero can find the attachment paths on each one. If you want new attachments moved to the external folder automatically on both computers, you’ll also need to configure the plugin on each. Simply opening files that are already linked doesn’t necessarily require the same plugin on every computer.

It works, but for me, there are a few too many things to keep track of. In particular, Zotero’s official mobile apps don’t support linked files, and those files aren’t uploaded through Zotero’s built-in file syncing either. Getting the folders sorted out on your computers doesn’t mean you can pick up where you left off in the official apps on an iPad or phone.

I wanted to keep my existing routine: import attachments into Zotero as usual, open another device, and just wait for them to sync.

Change the Attachment Storage, Keep Zotero’s Built-in Sync

First, it helps to clarify what “sync” means here. Zotero’s data syncing and file syncing are two separate things:

So even when I was using Nutstore, it wasn’t handling my entire Zotero library. Library data still synced through my Zotero account; Nutstore mainly handled the attachments. All I’m changing now is that part, replacing it with the WebDAV service provided by AList.

Annotations made in the built-in reader are saved in Zotero’s database, so everyday highlighting and note-taking don’t require the entire PDF to be transferred again each time. Only if you modify the PDF itself in an external reader do those changes need to sync with the attachment file.

WebDAV is already a supported file-syncing method in Zotero, so there’s no need for an additional attachment-syncing plugin. The official iOS and Android apps support it too. Still, it differs from Zotero Storage: WebDAV only handles personal libraries. Group attachments still require Zotero Storage, and Zotero’s web library can’t directly access attachments stored on this WebDAV server. When I say it feels much like Zotero’s own sync service, I mainly mean everyday use of a personal library in the apps.

The Key Decision: Route Transfers Through the AList Server

Successfully mounting Baidu Netdisk only tells you that AList can access it. It doesn’t mean Zotero will be able to download every attachment without issues.

AList’s Baidu Netdisk documentation notes that, when using the relevant download endpoints, requests for files larger than roughly 20 MB need to include User-Agent: pan.baidu.com. This applies to download requests—not to “all large-file uploads needing a custom UA.” The file size is also best understood as a rule of thumb from the documentation, not a threshold guaranteed to stay the same forever.

If WebDAV uses 302 redirects, AList passes the actual download URL to the client, which then downloads the file directly from Baidu Netdisk. The attachment bypasses the AList server, saving server bandwidth, but the client must supply the required request headers.

Zotero’s standard sync settings have no field for a custom UA. Using a networking tool such as Surge to rewrite requests just to sync attachments—and setting that up across devices—already sounded like more trouble than I wanted.

So I chose the WebDAV local proxy option. Here, “local” means the server running AList. The client connects only to AList, which requests files from Baidu Netdisk and passes them back to the client. AList’s Baidu Netdisk driver attaches the required UA to download links generated by the official API. The proxy uses that information for its requests, so Zotero doesn’t have to modify the headers itself.

The difference is easier to see with the two routes side by side:

Diagram: The top two sections show the paths taken by data and attachments. Read the 302 section from left to right in operational order. In the final step, Baidu Netdisk sends the attachment directly to Zotero, bypassing AList, so the client must meet the UA requirement. The 302 comparison applies only to downloads; uploads still pass through AList.

One important detail: AList’s “Web proxy” and “WebDAV policy” are separate settings. The former affects web previews, downloads, and similar actions; Zotero uses the latter. Turning on “Web proxy” alone does not set up proxying for Zotero. For the relevant settings, see the official WebDAV policy documentation.

How to Set It Up

The steps below assume AList is already deployed. I’ll use my domain, pan.xxu.do, and mount path, /Baidu, as examples. Replace them with your own domain and mount path when configuring your setup. Interface labels may vary slightly between versions.

1. Mount Baidu Netdisk. Follow AList’s Baidu Netdisk documentation to authorize access, and set the download API to Official. The mount path I use in AList is /Baidu. Before configuring Zotero, make sure this folder lists files correctly and that you can upload and download files.
2. Set this storage’s WebDAV policy to “Local proxy.” Some versions use slightly different wording, but the meaning is the same: transfers pass through the server running AList. Don’t select 302 here, and you don’t need to specify a separate download proxy server.
3. Create a dedicated AList account for Zotero. Give it permission to read, create, upload, update, and delete files in the sync folder. AList’s documentation calls for enabling “Webdav read” and “Webdav manage,” along with the relevant basic file-operation permissions; a read-only account cannot sync properly. In newer versions of AList, restrict accessible folders through the role scope. Changing the “Base path” alone is not a substitute for permission restrictions. For the exact setting names, see the WebDAV documentation and user permissions guide.
4. Have a working HTTPS address ready. My AList address is https://pan.xxu.do, and every device you want to sync must be able to reach it. The official mobile apps restrict plain HTTP, so using HTTPS with a valid certificate is simpler. See Zotero’s explanation for details.
5. Select WebDAV in Zotero. First, sign in to your Zotero account. Then go to Settings → Sync, switch file syncing for “My Library” to WebDAV, and enter your AList address and the AList username and password you prepared earlier. These are not your Baidu credentials or your Zotero account password.

AList’s WebDAV endpoint is /dav/. If the root folder this account sees over WebDAV corresponds to AList’s /, then with my domain and the /Baidu mount, the addresses are as follows:

In the screenshot, the URL field already has /zotero/ fixed to its right; Zotero appends this automatically. Select https as the protocol and enter only pan.xxu.do/dav/Baidu in the address field. Don’t manually append zotero again.Baidu must match the capitalization of the mount path. If the account’s WebDAV root already maps to /Baidu, enter only pan.xxu.do/dav in the address field, without adding the mount path again.

Once you’ve filled everything in, click “Verify Server.” Start syncing after verification succeeds. You can check the URL suffix rules and settings against the Zotero sync preferences documentation.

Double-Check When Migrating Existing Attachments

When moving from Nutstore, don’t assume that changing the WebDAV address will automatically move your attachments from the old service to the new one. If you previously selected “Download as needed,” in particular, your computer may only have the library items, while the PDFs are still on the old service.

A safer approach is to keep the old configuration on one computer first, change attachment downloads to “At sync time,” wait for the downloads to finish, and check that you can open your existing attachments. Then quit Zotero and make a separate backup of its data directory before changing the WebDAV address. Let that computer sync its local attachments to the new location. Keep the files on the old service until you’ve verified syncing across devices.

If you previously used linked attachments, you’ll also need to convert them to stored attachments through Tools → Manage Attachments before WebDAV can handle them. Don’t have a cloud storage client sync your entire Zotero data directory in real time: an active database file is not suited to that kind of syncing.

A successful server verification doesn’t mean every attachment has been tested, either. I recommend a practical check: add a small PDF and a real attachment well over 20 MB on one device. Once they’ve uploaded, download and open them on another device that doesn’t already have those files. Then add an annotation in the built-in reader and confirm that it appears on the other device. If small files work but large attachments fail, first check whether WebDAV is still using 302 redirects.

If your library items appear but your old attachments don’t, follow Zotero’s file sync troubleshooting guide to check the local files, upload results, and settings on both devices. Don’t treat “Replace Online Library” as a step in migrating attachments; that is a different operation.

The Trade-Off: Your Server Carries the Traffic

Local proxying shifts the hassle from the clients to the server, but it also makes the server a mandatory stop for every attachment transfer.

For downloads, files travel from Baidu Netdisk to the AList server, then from the server to your device. Uploads take the reverse route. If either leg is slow, suffers packet loss, or has an unstable connection, the whole experience suffers. A Baidu Netdisk subscription doesn’t automatically mean you’ll get full speed on both legs.

A rough bandwidth calculation helps put this in perspective: if the server can send data to your device at only 10 Mbps, the theoretical maximum is about 1.25 MB/s, before protocol overhead. You might not notice much with ordinary papers, but the difference becomes obvious when syncing several devices at once or migrating an entire library.

Proxying downloads also means the server receives and sends the same attachment. How your cloud server provider counts that traffic, and whether it charges only for outbound transfers, depends on your plan. During a large initial migration, you may also encounter cloud storage API rate limits, reverse proxy upload-size limits, or timeouts. If something goes wrong, first identify which part of the transfer the error relates to, rather than immediately increasing concurrency.

This combination therefore makes the most sense if you already have a Baidu Netdisk subscription and a machine with a decent network connection that can keep AList running. If you need to buy a subscription and rent a server just for this, you’ll need to work out the costs again. For me, the appeal was precisely that I was already using all these things.

So Far, So Good

After all the setup, everyday use is refreshingly uneventful: collect papers, open PDFs, make annotations, and let Zotero sync on its own. So far, sync speeds haven’t been noticeably different from when I used Nutstore. And changing the storage backend hasn’t left me maintaining a separate attachment folder and sync plugin.

Of course, this is my experience with my current setup. It doesn’t mean Baidu Netdisk’s API, authorization, or the server’s network connections will stay the same forever. Syncing is no substitute for an independent backup, either.

But at least for now, I no longer see that red exclamation mark in Zotero telling me I’ve run out of Nutstore’s free monthly transfer allowance. Putting things I’d already paid for and already had running to work solved a small problem that had been nagging at me. That feels pretty good.