Syncing Obsidian Vault w/ Remotely Save

[OlleKitty]

I tried to sync my Obsidian-Vault via WebDav with the Remotely Save plugin. It works fine with Nextcloud, so I guess it's not a Caddy problem. I keep getting part of an error "425 TOO" and I guess the next word should be "early". Has anybody had the same problem and solved it?

[jmrplens]

That "425 TOO" is the plugin's read-back of each upload hitting OpenCloud's post-processing window. Not Caddy. The same error is reported in remotely-save/remotely-save#1164 (against oCIS 8.0.1) and the status code itself is discussed in #3203.

The chain: Remotely Save uploads with PUT and immediately runs a PROPFIND on the same path to get its size and mtime (src/fsWebdav.ts, _writeFileFromRootFull: putFileContents then _statFromRoot). OpenCloud processes uploads asynchronously, and while a file is still in that state a PROPFIND answers a propstat with status HTTP/1.1 425 TOO EARLY (reva internal/http/services/owncloud/ocdav/propfind/propfind.go); a GET gets a plain 425. The webdav client the plugin uses splits that status line into three fields and drops the fourth, so the error text becomes Invalid response: 425 TOO (parseStat in webdav-client, statusLine.split(" ", 3)). Nextcloud, as far as I can see, writes the file synchronously, so there is no window and the same plugin works.

I reproduced it on OpenCloud 7.5.0 (reva v2.49.0) with the same client library: with no post-processing step configured, the stat right after the PUT comes back 200 OK (about 35 ms after the PUT, 10 of 10 uploads); with a post-processing step that takes 2 s, every upload fails with exactly Invalid response: 425 TOO, and the same stat succeeds once the step finishes. So on your instance something in post-processing takes longer than that round trip. The usual one is POSTPROCESSING_STEPS: "virusscan", which is what antivirus/clamav.yml in opencloud-compose sets: a ClamAV scan per file is well above 35 ms. If uploads never become readable at all, look in the logs for could not finalize upload: #3462 reports every upload stuck in processing on the posix driver with STORAGE_USERS_POSIX_ENABLE_FS_REVISIONS=true (7.2.4 to 7.5.0, unconfirmed so far), and in #1885 a separate mount point inside a space leaves uploads into that folder stuck; a stuck file answers 425 to every read for good.

Server-side fix, from the maintainer in #3203: OC_ASYNC_UPLOADS=false, so the PUT only returns when the file is ready. Checked in the same lab with the 2 s step still configured: the PUT returns in about 45 ms and the immediate stat is 200 OK. One caveat: that comment says it makes post-processing synchronous, but what I saw is the file being finalized as soon as the bytes were in (reva upload.go: "if the upload is synchronous ... finalize it now"), with the postprocessing service receiving BytesReceived and starting its step afterwards, so a virus scan in that mode runs after the file is already readable. If you run ClamAV, check what happens to an EICAR upload with async off before relying on it. The client-side fix would be for Remotely Save to retry the stat on 425; nobody has proposed it in remotely-save/remotely-save#1164 yet.

[micbar]

Thanks for answering that 425 question.

Disabling async uploads should not be the solution.
The question is why does it stay in 425. could be a wrongly configured virus scanner.

generally on the vault: it is really end to end encrypted, the server has only the encrypted content. So syncing with obsidian would only sync the encrypted content.

[jmrplens]

Agreed: switching async off is a workaround with a cost, which is why the answer flags that the scan then runs after the fact. The thing to fix is whatever keeps the file in processing.

@OlleKitty, the check that decides which case you are in: a minute after a failed sync, open one of the uploaded notes from the web UI. If it opens, post-processing is only slower than the plugin's stat (Remotely Save stats right after the PUT and does not retry), and the plugin is where the fix belongs. If it still shows as processing, the upload is stuck, and opencloud storage-users uploads sessions lists the sessions with their Processing state, scan date and scan result, with the reason in the antivirus and postprocessing logs. Two documented ways to get stuck with virusscan in POSTPROCESSING_STEPS: a scanner the antivirus service cannot reach ends the upload in the abort state whatever ANTIVIRUS_INFECTED_FILE_HANDLING says, and logs an error about the scanner (antivirus README), and a step name with no service behind it waits forever (postprocessing README). Once the scanner works again, opencloud storage-users uploads sessions --resume sends the resume event for the listed sessions.

On "vault": in Obsidian a vault is just the folder that holds the notes, so I read the question as a plain folder over WebDAV. If the target is one of OpenCloud's end-to-end encrypted folders, that is the other situation micbar describes and worth saying so, since then only the encrypted blobs would sync.