Files become zero bytes


I recently upgraded from ownCloud 9 to Nextcloud 9 which seemed to go ok but today I noticed that a file I frequently access had become zero bytes in size and I had to restore from a backup 4 days ago (well after the upgrade).

I’m using Linux Mint (ubuntu 14.04) with the Linux ownCloud desktop client from the Suse repos.

This has worried me a little and shaken my confidence in the syncing. I was wondering if this is a known issue and if anyone knows what can cause it to occur.

I’ve run a command to see if there are any other zero byte files in my documents and I’ve found five now - some of which I don’t have backups of far enough back.


That sounds a bit scary. If you still have the webserver logfiles, you can perhaps find out when and who actually made these changes. Do you use the versions-app, there might be the old version you could try to recover that.

Do you use the encryption app?

No encryption app (I encrypt the block device that NC uses) and no version-app at present. I do have the web logs though…

The last good backup of the file in question was on the evening of the Jan 1st, by the evening of the 2nd it was zero bytes.

So entries from web logs from the 1st and 2nd of Jan should cover it, I have the following:

(49 is my desktop, 34 is my laptop) - me [02/Jan/2017:10:18:02 +0000] “GET /remote.php/webdav/Documents/Passwords/passwords.kdb HTTP/1.1” 200 123515 “-” "Mozilla/5.0 (Linux) mirall/2.2.4" - me [02/Jan/2017:10:24:07 +0000] “PUT /remote.php/webdav/Documents/Passwords/passwords.kdb HTTP/1.1” 204 1117 “-” "Mozilla/5.0 (Linux) mirall/2.2.4" - me [02/Jan/2017:10:24:24 +0000] “GET /remote.php/webdav/Documents/Passwords/passwords.kdb HTTP/1.1” 200 4734 “-” “Mozilla/5.0 (Linux) mirall/2.2.4”

I’ll put a script together which runs the following command each day and alerts me if there are any more 0 byte files:

find $dataDir/ -size 0

The only other thing worth mentioning is that I reinstalled the ownCloud client on the 2nd Jan between 10 and 11 am. I think I flipped between a couple of the Suse repos because I wasn’t sure which one to use. Settled on the following:

deb /

but did briefly use one that also had qt5 or something in the url

What other files types were concerned by this problem? I suppose the passwords is some sort of container. I had some problems with TrueCrypt containers where I needed to enable that if it updates the changing date of a file if there have been changes.

So far I have had it happen to a .txt, .rtf, .odp, .jpg and .kdb but I’m not sure when all happened.

For your .kdb file the client on your laptop wrote a new file. Logging is not enabled by default on the clients, you can however start it with logging. Did you change the files which were set to 0? Or copy their folders?

I’m shocked!

find $nextcloud_data_dir -size 0 -type f

I my case it happened on a couple of pdf files an one txt file.

I don’t know why they have a file size of 0 bytes now and when it happened!


I also had that for 3 mp3 files some time ago. Versions were not available for them, so this seemed to be not tracked correctly as change. As I realised it some time later I could not find related log messages. I regularly watch out for 0 byte files now, but didn’t found one since that.

Then please open a bug report on and fill out the template.

I had this on NC11 (running since sevrl. weeks) yesterday, for a first and only time when I tried to open a file with Collabora. Collabora got stuck and file went to 0. No idea if this was a Collabora thing or some other issue.

  • Debian 8.x / MariaDB 10.x / Apache 2.4.x) / PHP 5.6
  • Files not encrypted

As it happend only once, I restored the file and didn’t bother anymore about it. Unfortunately I can’t remember what office format the file was.

I’ll watch if this happens again and will try to document it.


1 Like

Same problem with me.

I found this problem several days ago.

I use little workaround backup nextcloud data folder with command:
rsync -ah --progress --min-size=1 --update /var/www/html/nextcloud/data .

I created an issue on github for that one. In a bit diletantic way, as I’m way too tired after 14h of work - but at least it’s in there.

1 Like

thanks. ref:

1 Like

Owncloud users also reporting the “zero file size bug”:

Running Rsnapshot on the Nextcloud data directory is a good idea, peace of mind that you can revert any file back to a previous state.

I also, now, run this script every night, if any zero byte file exist in an array of given filesystems it emails a list of them out.



emSub="Warning: Nextcloud Contains 0 Byte Files"

for fs in "${filesystems[@]}"; do

        while read -d '' -r; do
    		arr+=( "$REPLY" )
		done < <(find $fs -size 0 -print0)


if [[ ! -z ${arr[@]} ]]; then

	echo ${arr[@]} | mail -s "$emSub" "$emAdy"


There is a small fix of code that helps to debug this problem:

Stay tuned on the github issue!

I have installed a fresh version of NC 13 but the problem still persists.

Thanks to the script of @feisar i could find it out.


So this is a warning to all Nextcloud users: don’t trust the desktop client!


Today i had it again! One file of 65 GB of data had 0 bytes filesize after syncing it with the desktop client.

For those who want to verify that issue:

  • Install a Nextcloud instance on localhost in a virtual machine
  • Sync a huge amount of data in one run with the desktop sync client, lets say 100 GB
  • after it run the script of @feisar
  • if no errors then 100 GB upload is not enough
  • delete everything and retry with more data then 100 GB
  • if the srcript found zero byte files, open web browser, locate the file and watch the file size: does not display zero bytes (!) but can’t be opened of course. This could cause preview-plugin or fulltextsearch-plugin to run forever

With that error, Nextcloud can’t be recommended for business, sorry guys. @tflidd
Only for private use to sync and share small amount of data with your peers.

The Nextcloud desktop client, right? Because I haven’t seen this affect my array and I don’t use the client.

1 Like