I constantly receive “Failed to write data on the client.” errors which I have been unable to resolve for days.
I start synchronizing a library, a couple hundred MBs can be downloaded, then the client stops and shows the error message. The only workaround so far is to quit Seafile, go to the Explorer, uncheck the “read-only” attribute for the folder, apply this to all subfolders as well and restart Seafile. It then downloads some more files before stopping again. There is no pattern in how much can be downloaded at once. I cannot keep doings this for hours before everything is downloaded.
Now for the details:
Disk space is not the issue.
Client runs on Windows 10, Server on Raspberry Pi.
It only happens on one particular device. Everywhere else everything works fine.
It does not seem to be a particular library. All libraries seem to fail at some point. On another device I could freshly checkout libraries, so it does not seem to be a server issue.
I completely uninstall Seafile, installed the most recent version and made sure all configuration files were deleted (e.g. the seafile-data folder) before trying again. Does not seem to be a Seafile client configuration issue.
On the same machine, some time ago, everything worked just fine. I can’t tell what changed.
I have no anti-virus tools installed except for standard Windows security stuff. I checked all settings, nothing seems bad (e.g. Ransomware protection is also switched off etc.)
The “read-only” attribute is odd. It seems to temporarily resolve the issue, but at the same time, not all files are write protected (I get the black square instead of the black check mark). The same seems to be true for all my folders, e.g. there seem to be some write protected system files in basically all folders. I can’t tell, what would be write protected or why it constantly resets.
I tried different paths as well. No matter where I check out to, the error remains the same.
I found no further information regarding seafile looking for the error message. It seems a bit like something is constantly turning on write-protection while the folder is being synchronized but I cannot figure out how this could happen or how it could be stopped.
When I have a copy of a library folder and use it to synchronize a server library with an existing folder, this seems to work. After some computation, the library shows as synchronized and when I make changes to files, everything seems to work as intended. It seems to be only a problem with initial library download or the download of a large amount of data at once in general.
Needless to say copying libraries via external harddrives is not why I have a seafile server, so this is not a solution but merely something I tried to debug the problem.
[08/26/23 16:22:30] Transition clone state for 094b2ab5 from [init] to [check server].
[08/26/23 16:22:30] Transition clone state for 094b2ab5 from [check server] to [fetch].
[08/26/23 16:22:30] Transfer repo '094b2ab5': ('normal', 'init') --> ('normal', 'check')
[08/26/23 16:22:30] Transfer repo '094b2ab5': ('normal', 'check') --> ('normal', 'commit')
[08/26/23 16:22:30] Transfer repo '094b2ab5': ('normal', 'commit') --> ('normal', 'fs')
[08/26/23 16:22:52] Transfer repo '094b2ab5': ('normal', 'fs') --> ('normal', 'data')
[08/26/23 16:26:19] [block bend] failed to commit block 094b2ab57-:b0dd4e3948e818f19db2dfe246440: Permission denied
[08/26/23 16:26:19] Failed to commit block b0dd4eb57fab2dfe246440 in repo 094b2ab5.
[08/26/23 16:26:19] Transfer failed.
[08/26/23 16:26:19] libcurl failed to GET https://server.com/seafhttp/repo/094b2ab5-136b-4df4-a237-/block/07699eb9c48af2c62ddfdcb46e35867d80890a83: Failed writing received data to disk/application.
[08/26/23 16:26:19] Transfer failed.
[08/26/23 16:26:19] libcurl failed to GET https://server.com/seafhttp/repo/094b2ab5-136b-4df4-a237-/block/dd4ae96bf735fd24c58297103e826703a06cc0ff: Failed writing received data to disk/application.
[08/26/23 16:26:19] Transfer failed.
[08/26/23 16:26:20] libcurl failed to GET https://server.com/seafhttp/repo/094b2ab5-136b-4df4-a237-/block/bc08f03d93effc17a1dae0e6adc6a3603cbd6d3d: Failed writing received data to disk/application.
[08/26/23 16:26:20] Transfer failed.
[08/26/23 16:26:20] Transfer repo '094b2ab5': ('normal', 'data') --> ('error', 'finished')
[08/26/23 16:26:20] Transition clone state for 094b2ab5 from [fetch] to [error]: Failed to write data on the client. Please check disk space or folder permissions.
The only thing I learn is that the data could not be written to disk…
Update: The issue is unrelated to file attributes. Simply restarting Seafile completely lets it continue the download for a little bit, the above mentioned step of removing the read-only attribute for all subfolders is not required.
I assume some other tool is temporarily doing something in the folder. Seafile gets very irritated by this and completely stops working until the next restart.
Is there any way to find out which process is interfering with the folder (OS is Win10)? Is there any way to tell Seafile to just try again a minute later when the file is not opened by another process anymore?
I have the exact same problem, and the culprit is … the OS anti-virus (on my side, but it’s quite probable that you have the same root cause). The anti-virus falsely detects some blocks as viruses, and prevents them to be written on disk, failing the sync.
As i don’t have any way to exclude anything in that antivirus, i fear i’m stuck on my side.
I fixed the problem by restarting Seafile every 20 minutes for a day or so. Very annoying, but once everything was synchronized it seemed fine.
I think in general there can be many thinks interfering with the sync process. Not all are avoidable or even easily detecable, so what would fix it for my case would be if seafile just retries on its own periodically. Probably there should be an option to enable and disable this and this option should be mentioned in the “failed to write to disc” error, so that people can easily fix it themself.
In case of the antivirus, it seems like the fault is on the antivirus side and I don’t know if seafile could be changed in any way to avoid this.