Server: Files getting set to 0 in data folder
Steps to reproduce
- find /srv/ncdata/ -size 0 -type f | wc -l
- Result: 215 files found
- No other way to reproduce, I suddenly realized I had lost a file to zero and did some investigation, as some other nextcloud forum's users wrote about the same issue in https://help.nextcloud.com/t/files-become-zero-bytes/7214
Expected behaviour
Files should not randomly getting set to 0
Actual behaviour
Hi guys,
I'm one of those losing files to zeros. I thought it's better to continue in here, rather than spamming the forum's thread about this issue.
I'm on NC11RC1 since yesterday and I do have 215 files in the data folder set to zero - but I for sure already had one file on NC11 final that was set to zero and I had to restore it from a backup. Maybe the other 214 were lost too already on NC11 final.
a) 13 files related to one (and only one) frequent user's data
10 files in ncdata/ncuser01/files/01_Daten/
File extensions: .ini .txt .docx .exe .cfg .bin
3 files:
ncdata/ncuser01/files_versions/MyCloud/Tesfile01.txt.v1474618386
ncdata/ncuser01/files_trashbin/files/New Text Document.txt.d1475085009
ncdata/ncuser01/files_trashbin/files/New Text Document.txt.d1480781891
b) 199 files related to "updater-data" in the data folder
187 files in ncdata/updater-50793ab339aa5/
6 files in ncdata/updater-data/checkpoint/9.0.0.19-570dfac02c766/apps/
6 files in ncdata/updater-data/checkpoint/9.0.1.3-573246e809595/apps/
c) 3 other files in data root:
ncdata/.ocdata
ncdata/index.html
ncdata/appdata_50793ab339aa5/preview/16024/64-64-crop.png
It's midnight now, and I came home from work at 10pm, so please don't ask for more infos now.
Thanks, kind regards
Server configuration
Debian Jessie 8.6 (x64) - SMP Debian 4.8.11-1~bpo8+1 (2016-12-14) x86_64 GNU/Linux
Apache/2.4.25 (Debian)
mysql Ver 15.1 Distrib 10.0.28-MariaDB
PHP 5.6.29-0+deb8u1
NC 11.0.1 RC1 (beta)
Updated from NC11 final with Webgui updater
*Original clean manual installation of Nextcloud 9 (from nextcloud.com download) and then additionally migrated data from an old owncloud installation (which itself came the long way from OC 3.X) *
Signing status:
Signing status
Integrity checker has been disabled. Integrity cannot be verified.`
List of activated apps:
App list
Enabled:
- activity: 2.4.1
- admin_audit: 1.1.0
- announcementcenter: 3.0.0
- apporder: 0.3.3
- audioplayer: 1.4.0
- bookmarks: 0.9.1
- calendar: 1.4.1
- comments: 1.1.0
- contacts: 1.5.2
- dav: 1.1.1
- external: true
- federatedfilesharing: 1.1.1
- federation: 1.1.1
- files: 1.6.1
- files_accesscontrol: 1.1.2
- files_automatedtagging: 1.1.1
- files_external: 1.1.2
- files_pdfviewer: 1.0.1
- files_retention: 1.0.1
- files_sharing: 1.1.1
- files_texteditor: 2.2
- files_trashbin: 1.1.0
- files_versions: 1.4.0
- files_videoplayer: 1.0.0
- gallery: 16.0.0
- gpxedit: 0.0.3
- gpxpod: 2.0.0
- keeweb: 0.3.0
- logreader: 2.0.0
- lookup_server_connector: 1.0.0
- mozilla_sync: true
- nextcloud_announcements: 1.0
- notes: 2.1.0
- notifications: 1.0.1
- ocsms: 1.11.4
- password_policy: 1.1.0
- polls: 0.7.2
- provisioning_api: 1.1.0
- qownnotesapi: 16.12.0
- rainloop: 4.26.0
- richdocuments: 1.1.25
- serverinfo: 1.1.1
- sharebymail: 1.0.1
- spreed: 1.1.2
- spreedme: 0.3.5
- survey_client: 0.1.5
- systemtags: 1.1.3
- tasks: 0.9.4
- templateeditor: 0.2
- theming: 1.1.1
- twofactor_backupcodes: 1.0.0
- updatenotification: 1.1.1
- user_ldap: 1.1.1
- workflowengine: 1.1.1
Disabled: - encryption
- files_markdown
- firstrunwizard
- user_external
- user_saml
The content of config/config.php:
Config report
{
"system": {
"datadirectory": "\/srv\/ncdata",
"dbtype": "mysql",
"version": "11.0.1.1",
"installedat": "1331029597.1919",
"lastupdatedat": "1343136183.1441",
"installed": true,
"loglevel": 2,
"instanceid": "50793ab339aa5",
"ldapIgnoreNamingRules": false,
"maintenance": false,
"memcache.local": "\\OC\\Memcache\\APCu",
"theme": "",
"mail_smtpmode": "smtp",
"mail_smtphost": "valid.smtp.host.xxx",
"mail_smtpport": "465",
"mail_smtptimeout": 30,
"mail_smtpauth": 1,
"mail_smtpauthtype": "LOGIN",
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"allow_user_to_change_display_name": true,
"enable_avatars": true,
"knowledgebaseenabled": false,
"enable_certificate_management": true,
"trusted_domains": [
"localhost",
"*someIP*",
"some.dom.tld"
],
"appcodechecker": false,
"custom_csp_policy": "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src *; font-src 'self' data:; media-src *",
"share_folder": "\/Shared",
"mail_from_address": "somevalidemail",
"mail_domain": "dom.tld",
"dbname": "nextcloud",
"dbhost": "localhost",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"forcessl": true,
"defaultapp": "files",
"mail_smtpsecure": "ssl",
"secret": "***REMOVED SENSITIVE VALUE***",
"appstoreenabled": true,
"appstoreurl": "https:\/\/apps.nextcloud.com\/api\/v0",
"appstore.experimental.enabled": true,
"trashbin_retention_obligation": "auto",
"updater.release.channel": "beta",
"ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory",
"updater.secret": "***REMOVED SENSITIVE VALUE***"
}
}
Are you using external storage, if yes which one: No
Are you using encryption: no
Are you using an external user-backend, if yes which one: ActiveDirectory (but not really used, still local users)
LDAP config
</details>
### Client configuration
**Browser:** Firefox 50.1.0
**Operating system:** Debian 8.6 KDE Plasma / Windows 7
### Logs
#### Web server error log
<details>
<summary>Web server error log</summary>
Errorlog from when?
</details>
#### Nextcloud log (data/nextcloud.log)
<details>
<summary>Nextcloud log</summary>
Nextcloud log from when?
</details>
#### Browser log
<details>
<summary>Browser log</summary>
From when?```
mikelupe
All 60 comments
Thanks for the detailed report!
Is there anything in the nextcloud.log or in your apache/nginx error.log?
nickvergessen
on 13 Jan 2017
Sorry the formatting mess...
I'll have to investigate the logs when I'll find some time. The problem is, the only trigger for me to realize there's zeros coming was when opening a file in Collabora, CODE got stuck. Then I saw the file went zero, but didn't have the time to investigate further (besides of restoring the file from backup). The "big" research I did with finding the 215 files was much later, like 2 days later or so...
mikelupe
on 13 Jan 2017
I also have that issue.
Unfortunately i can't say when it happened. Therefore i'm unable to look at the log files.
I only can warn everyone about this behavior!
Check from time to time if files in your data folder becomes 0 bytes.
find $nextcloud_data_folder -size 0 -type f
Here are some more users of Nextcloud with that zero bytes bug:
https://help.nextcloud.com/t/files-become-zero-bytes/7214
Sanookmakmak
on 13 Jan 2017
For one of the users it could have been the client which overwrites the file:
https://help.nextcloud.com/t/files-become-zero-bytes/7214/3
Does this only concern users who sync their files with the nc-client? All longer existing setups with upgrade history? Zero files also happen on local storage, non shared files & folders? If you share a bit more about the other configs, it's easier to find a pattern.
tflidd
on 14 Jan 2017
@tflidd - well, for me it's indeed just for the only user syncing with desktop clients (Linux & Windows). All other user's files haven't been touched appearently. Local storage only, non shared files or folders. Quite "simple and small" personal setup. I didn't do the check on the company's NC yet though.
@Sanookmakmak - let's try to approach this issue in a calm way. Creating some panic doesn't help. Please give some closer insight on the zeroed files. I know it's boring - that's how it felt when I created the issue yesterday. But maybe this way we can advance faster on it.
thanks
mikelupe
on 14 Jan 2017
I can only say that i use the Linux and Windows client, sorry. I've uploaded the files about half a year ago and i really don't have an idea when and why the files have been zeroed. I found them coincidentally. But i will keep an eye on it if it happens again.
And i don't have a backup because Nextcloud is my backup solution. That's why i feel i little bit panic :-(
Sanookmakmak
on 14 Jan 2017
I see - Be careful, it's "dangerous" and not recommended to use OC or NC as the sole backup solution, even if you would use the "versions" app. The NC server data should always be backupped. That's what the big cloud providers also do. Otherwise they would be in big trouble.
Can you provide some information about the system setup?
Operating System
Kernel (uname -a)
Webserver engine ("apachectl -V" e.g.)
Database ("mysql --version" e.g.)
PHP Version ("php --version")
Thanks
mikelupe
on 14 Jan 2017
This information is from today, but the issue could also happened half a year ago and of course there were older versions installed. As i told before, i can't say when those files were zeroed.
Operating System
Ubuntu 16.041 x64 Server
Clients: Linux Mint 18 with Owncloud client 2.2.4 of SuSE repo
Windows 7 with Nextcloud client 2.2.4 build 2
Kernel (uname -a)
Linux server 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Webserver engine (apachectl -V)
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2016-07-14T12:32:26
Server's Module Magic Number: 20120211:52
Server loaded: APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"
Database (mysql --version)
mysql Ver 15.1 Distrib 10.0.28-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
PHP Version (php --version)
PHP 7.0.13-0ubuntu0.16.04.1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.13-0ubuntu0.16.04.1, Copyright (c) 1999-2016, by Zend Technologies
Great. If you find the time, could you analyze your "find $nextcloud_data_folder -size 0 -type f" command in an editor and filter down the major folders of the affected files (more or less as I did in the issue description).
And "sudo -u www-data php /var/www/your_nc_folder/occ app:list" - so the devs and ops got even more stuff to work with :)
mikelupe
on 14 Jan 2017
find $nextcloud_data_folder -size 0 -type f
./Archiv/Musikarchiv/Artists/K-O/Miles Davis/Blue Bird - Legendary Savoy Sessions/Miles Davis - Parker's Mood (feat. Charlie Parker).mp3
php occ app:list
Enabled:
- activity: 2.4.1
- admin_audit: 1.1.0
- announcementcenter: 3.0.0
- apporder: 0.3.3
- audioplayer: 1.4.0
- bookmarks: 0.9.1
- calendar: 1.4.1
- comments: 1.1.0
- contacts: 1.5.2
- dav: 1.1.1
- direct_menu: 0.10.0
- federatedfilesharing: 1.1.1
- federation: 1.1.1
- files: 1.6.1
- files_accesscontrol: 1.1.2
- files_automatedtagging: 1.1.1
- files_downloadactivity: 1.0.0
- files_external: 1.1.2
- files_markdown: 1.0.0
- files_pdfviewer: 1.0.1
- files_reader: 0.8.1
- files_retention: 1.0.1
- files_sharing: 1.1.1
- files_texteditor: 2.2
- files_trashbin: 1.1.0
- files_versions: 1.4.0
- files_videoplayer: 1.0.0
- firstrunwizard: 2.0
- gallery: 16.0.0
- gpxedit: 0.0.3
- gpxpod: 2.0.0
- keeweb: 0.3.0
- logreader: 2.0.0
- lookup_server_connector: 1.0.0
- mail: 0.6.2
- news: 10.1.0
- nextcloud_announcements: 1.0
- notifications: 1.0.1
- ocr: 2.0.0
- ocsms: 1.11.4
- ojsxc: 3.0.2
- password_policy: 1.1.0
- provisioning_api: 1.1.0
- richdocuments: 1.1.25
- serverinfo: 1.1.1
- sharebymail: 1.0.1
- spreed: 1.1.2
- spreedme: 0.3.5
- survey_client: 0.1.5
- systemtags: 1.1.3
- tasks: 0.9.4
- theming: 1.1.1
- twofactor_backupcodes: 1.0.0
- twofactor_totp: 0.5.0
- twofactor_u2f: 0.1.0
- updatenotification: 1.1.1
- user_ldap: 1.1.1
- user_saml: 1.2.2
- workflowengine: 1.1.1
@icewind1991 @rullzer any idea? Seems like filesystem or syncing causes an issue.
nickvergessen
on 16 Jan 2017
I've posted a script here https://help.nextcloud.com/t/files-become-zero-bytes/7214/17 which will help alert close to the time it happens. The Apache logs don't seem to help much, I caught them when one file was zero'd and they just showed one client putting and the other getting.
Anyone know which log file is going to be best to look at and would turning on debugging help?
feisar
on 17 Jan 2017
Can you post those two lines? The GET and the PUT?
nickvergessen
on 18 Jan 2017
Sure,
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)
192.168.0.34 - 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"
192.168.0.34 - 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"
192.168.0.49 - 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"
And here's what looks relevant from the nextcloud.log
{"reqId":"Lkxh6CnAZ4QR+Y6jP+eo","remoteAddr":"192.168.0.49","app":"admin_audit","message":"Login attempt: "me"","level":1,
"time":"2017-01-02T10:17:10+00:00","method":"PROPFIND","url":"/remote.php/webdav/","user":"--","version":"9.0.55.2"}
{"reqId":"Lkxh6CnAZ4QR+Y6jP+eo","remoteAddr":"192.168.0.49","app":"admin_audit","message":"Login successful: "me"","level"
:1,"time":"2017-01-02T10:17:10+00:00","method":"PROPFIND","url":"/remote.php/webdav/","user":"me","version":"9.0.55.2"
}
{"reqId":"O6K8tsA1LpcV4MucFfoB","remoteAddr":"192.168.0.34","app":"admin_audit","message":"Login attempt: "me"","level":1,
"time":"2017-01-02T10:17:47+00:00","method":"PROPFIND","url":"/remote.php/webdav/","user":"--","version":"9.0.55.2"}
{"reqId":"O6K8tsA1LpcV4MucFfoB","remoteAddr":"192.168.0.34","app":"admin_audit","message":"Login successful: "me"","level"
:1,"time":"2017-01-02T10:17:47+00:00","method":"PROPFIND","url":"/remote.php/webdav/","user":"me","version":"9.0.55.2"
}
{"reqId":"kutzpgoHBgNmYs0iM98J","remoteAddr":"192.168.0.34","app":"admin_audit","message":"File accessed: "/Documents/Passwords/passwords.kdb"","level":1,"time":"2017-01-02T10:18:02+00:00","method":"GET","url":"/remote.php/webdav/Documents/Passwords/passwords.kdb","user":"me","version":"9.0.55.2"}
...
{"reqId":"SJceIZsYT6112ImWuKvD","remoteAddr":"192.168.0.34","app":"admin_audit","message":"File updated: "/Documents/Passwords/passwords.kdb"","level":1,"time":"2017-01-02T10:24:09+00:00","method":"PUT","url":"/remote.php/webdav/Documents/Passwords/passwords.kdb","user":"me","version":"9.0.55.2"}
{"reqId":"SJceIZsYT6112ImWuKvD","remoteAddr":"192.168.0.34","app":"admin_audit","message":"File written to: "/Documents/Passwords/passwords.kdb"","level":1,"time":"2017-01-02T10:24:09+00:00","method":"PUT","url":"/remote.php/webdav/Documents/Passwords/passwords.kdb","user":"me","version":"9.0.55.2"}
...
{"reqId":"w9GMJE8VNhqyuat1UT5X","remoteAddr":"","app":"cron","message":"Run OC\Command\CommandJob job with ID 137","level":0,"time":"2017-01-02T10:30:02+00:00","method":"--","url":"--","user":"--"}
{"reqId":"w9GMJE8VNhqyuat1UT5X","remoteAddr":"","app":"files_versions","message":"Mark to expire /Documents/Passwords/passwords.kdb next version should be 1482250718 or smaller. (prevTimestamp: 1482337118; step: 86400","level":1,"time":"2017-01-02T10:30:02+00:00","method":"--","url":"--","user":"--"}
{"reqId":"w9GMJE8VNhqyuat1UT5X","remoteAddr":"","app":"files_versions","message":"Mark to expire /Documents/Passwords/passwords.kdb next version should be 1479453393 or smaller. (prevTimestamp: 1480058193; step: 604800","level":1,"time":"2017-01-02T10:30:02+00:00","method":"--","url":"--","user":"--"}
{"reqId":"w9GMJE8VNhqyuat1UT5X","remoteAddr":"","app":"files_versions","message":"Expire: /Documents/Passwords/passwords.kdb.v1482337032","level":1,"time":"2017-01-02T10:30:02+00:00","method":"--","url":"--","user":"--"}
{"reqId":"w9GMJE8VNhqyuat1UT5X","remoteAddr":"","app":"files_versions","message":"Expire: /Documents/Passwords/passwords.kdb.v1479646724","level":1,"time":"2017-01-02T10:30:02+00:00","method":"--","url":"--","user":"--"}
{"reqId":"w9GMJE8VNhqyuat1UT5X","remoteAddr":"","app":"cron","message":"Finished OC\Command\CommandJob job with ID 137","level":0,"time":"2017-01-02T10:30:02+00:00","method":"--","url":"--","user":"--"}
...
feisar
on 24 Jan 2017
Without any further info I'm inclined to believe that this is a client side issue, either a bug in the sync client or some situation on the client seed causing the sync client to see a 0 byte file.
To further investigate the situation you can try applying this patch which will log the stacktrace anytime a 0 byte file is written
icewind1991
on 24 Jan 2017
No feedback since half a year. I will close this. Once you have more details we can of course reopen this ticket.
MorrisJobke
on 18 Jul 2017
I had the same problem in 2012 and in 2015 (inbetween and after that I stopped using Owncloud/Nextcloud for file sync). I found several issues like this. I wanted to link to the issue below, that seems to have some more details according to this phenomenon.
Could a first workaround be an option to forbid the client to sync any files with 0 bytes?
https://github.com/owncloud/client/issues/4583
The first report of this is from 2013:
https://github.com/owncloud/client/issues/1218
I have hosted Owncloud on all-inkl.com, so I can't say much about the server setup. I used the owncloud client on windows for synchronization. I found several pdf-files synced down to 0 bytes. On my computers as well as on the server. Furthermore, I could not restore old versions of these files.
FeralFox
on 12 Aug 2017
hello, experienced something similar today on NC 13.0.0 ( originally 12.0.5 updated to 13.0.0 without errors )
Nextcloud server 13.0.0 (12.0.5 updated)
based A8-6500 8GO RAID6 8*6TO
4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)
/ apache 2.4.29 / php 7.0.27 / 10.1.26-MariaDB / mysqlnd 5.0.12
/ phpadmin 4.6.6deb4 / Redis server v=3.2.6 / HTTP2 / Python 2.7.13
Created a few days ago some folder, and copy/past files/pic to it
also open and modified files directly from GUI for txt files
and i got this in GUI logging:
Info | files_versions | Expire: /test_raw/TRAVAILENCOURS_MELIRE.txt.v1518400652 | 2018-02-14T12:15:03+0100
-- | -- | -- | --
Info | files_versions | Expire: /test_raw/TRAVAILENCOURS_MELIRE.txt.v1518400674 | 2018-02-14T12:15:03+0100
Info | files_versions | Expire: /test_raw/TRAVAILENCOURS_MELIRE.txt.v1518400719 | 2018-02-14T12:15:03+0100
Info | files_versions | Expire: /test_raw/TRAVAILENCOURS_MELIRE.txt.v1518400731 | 2018-02-14T12:15:03+0100
Info | files_versions | Mark to expire /test_raw/TRAVAILENCOURS_MELIRE.txt next version should be 1518314339 or smaller. (prevTimestamp: 1518400739; step: 86400 | 2018-02-14T12:15:03+0100
Info | files_versions | Mark to expire /test_raw/TRAVAILENCOURS_MELIRE.txt next version should be 1518314339 or smaller. (prevTimestamp: 1518400739; step: 86400 | 2018-02-14T12:15:03+0100
Info | files_versions | Mark to expire /test_raw/TRAVAILENCOURS_MELIRE.txt next version should be 1518314339 or smaller. (prevTimestamp: 1518400739; step: 86400 | 2018-02-14T12:15:03+0100
Info | files_versions | Mark to expire /test_raw/TRAVAILENCOURS_MELIRE.txt next version should be 1518314339 or smaller. (prevTimestamp: 1518400739; step: 86400 | 2018-02-14T12:15:03+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518292863 | 2018-02-14T03:39:40+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518293056 | 2018-02-14T03:39:40+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518293304 | 2018-02-14T03:39:40+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518293316 | 2018-02-14T03:39:40+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518293322 | 2018-02-14T03:39:40+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518297813 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518297823 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518297831 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298004 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298011 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298102 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298139 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298151 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298162 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298169 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298186 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298196 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298243 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298252 | 2018-02-14T03:39:39+0100
Info | files_versions | Expire: /Hardnas/Structure.txt.v1518298260 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
Info | files_versions | Mark to expire /Hardnas/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400 | 2018-02-14T03:39:39+0100
and from nextcloud.log file:
qId":"5R2zWJgL6QxHtEpHNsDR","level":3,"time":"2018-02-13T18:34:42+00:00","remoteAddr":"90.112.162.211","user":"nextadmin","app":"core","method":"POST","url":"\/index.php\/settings\/ajax\/enableapp.php","message":"Could not download app camerarawpreviews","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"SspLYznfi8MM6X2CiqUk","level":3,"time":"2018-02-13T18:34:49+00:00","remoteAddr":"90.112.162.211","user":"nextadmin","app":"core","method":"POST","url":"\/index.php\/settings\/ajax\/uninstallapp.php","message":"can't remove app CameraRawPreviews. It is not installed.","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"EKy2kOj2Hs1OtcJWSXcy","level":3,"time":"2018-02-13T18:34:52+00:00","remoteAddr":"90.112.162.211","user":"nextadmin","app":"core","method":"POST","url":"\/index.php\/settings\/ajax\/uninstallapp.php","message":"can't remove app CameraRawPreviews. It is not installed.","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/Hardnas\/Structure.txt next version should be 1518211889 or smaller. (prevTimestamp: 1518298289; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298260","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298252","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298243","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298196","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298186","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298169","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298162","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298151","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298139","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298102","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298011","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518298004","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518297831","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518297823","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:39+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518297813","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:40+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518293322","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:40+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518293316","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:40+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518293304","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:40+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518293056","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"FMrJEyepRcDVvsqRIpem","level":1,"time":"2018-02-14T02:39:40+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/Hardnas\/Structure.txt.v1518292863","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.140 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"uZntwgct5QIfS4Mu3ieF","level":1,"time":"2018-02-14T11:15:03+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/test_raw\/TRAVAILENCOURS_MELIRE.txt next version should be 1518314339 or smaller. (prevTimestamp: 1518400739; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.167 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"uZntwgct5QIfS4Mu3ieF","level":1,"time":"2018-02-14T11:15:03+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/test_raw\/TRAVAILENCOURS_MELIRE.txt next version should be 1518314339 or smaller. (prevTimestamp: 1518400739; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.167 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"uZntwgct5QIfS4Mu3ieF","level":1,"time":"2018-02-14T11:15:03+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/test_raw\/TRAVAILENCOURS_MELIRE.txt next version should be 1518314339 or smaller. (prevTimestamp: 1518400739; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.167 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"uZntwgct5QIfS4Mu3ieF","level":1,"time":"2018-02-14T11:15:03+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Mark to expire \/test_raw\/TRAVAILENCOURS_MELIRE.txt next version should be 1518314339 or smaller. (prevTimestamp: 1518400739; step: 86400","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.167 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"uZntwgct5QIfS4Mu3ieF","level":1,"time":"2018-02-14T11:15:03+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/test_raw\/TRAVAILENCOURS_MELIRE.txt.v1518400731","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.167 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"uZntwgct5QIfS4Mu3ieF","level":1,"time":"2018-02-14T11:15:03+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/test_raw\/TRAVAILENCOURS_MELIRE.txt.v1518400719","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.167 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"uZntwgct5QIfS4Mu3ieF","level":1,"time":"2018-02-14T11:15:03+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/test_raw\/TRAVAILENCOURS_MELIRE.txt.v1518400674","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.167 Safari\/537.36","version":"13.0.0.14"}
{"reqId":"uZntwgct5QIfS4Mu3ieF","level":1,"time":"2018-02-14T11:15:03+00:00","remoteAddr":"90.112.162.211","user":"--","app":"files_versions","method":"GET","url":"\/cron.php","message":"Expire: \/test_raw\/TRAVAILENCOURS_MELIRE.txt.v1518400652","userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.167 Safari\/537.36","version":"13.0.0.14"}
stratege1401
on 14 Feb 2018
This also happens to me on a regular basis. The files seems to get 0ed on the server storage, not on the client side. A touch on those files to force the upload of valid contents resolve it but I'm afraid it may not always do.
Please reopen this issue as it is really frightening to get files erased randomly. I'm available to do some tests if needed. For what it's worth it happened on several files when moved from a subfolder to another, in the same synced folder.
I use a Windows client and several Linux clients (stable repository). Client version (Windows): 2.3.3. Server version: 12.0.4, on Debian Stretch.
Dece
on 22 Mar 2018
Did you try to add the extended logging from https://github.com/nextcloud/server/issues/3056#issuecomment-274770918?
And please try with the latest NC 12 version, not that it was accidentally fixed:
https://nextcloud.com/changelog/#latest12
tflidd
on 22 Mar 2018
I fortunately didn't have these problems anymore, after my last clean-up (about an year ago). It think it was a combination of Linux/Windows desktop clients and an old Linux owncloud client, but I'm not 100% sure of it. Sorry - I can't remember and am not able to describe the solving. It was one of these moments of "oh ok, it didn't happen anymore".
mikelupe
on 23 Mar 2018
@tflidd NC12 does not fix the issue, for 6 shared folders I have empty files appearing in 3 tonight, several days after the upgrade. I will try to enable extended logging tomorrow.
Dece
on 1 Apr 2018
This patch seems to cause an issue:
{"reqId":"peDOLrsekBLqkxn50o5W","level":3,"time":"2018-04-05T19:30:23+00:00","remoteAddr":"192.168.1.1","user":"<edited>","app":"PHP","method":"GET","url":"\/remote.php\/dav\/files\/<edit>.jpeg","message":"Undefined variable: stream at \/var\/www\/nuaj\/lib\/private\/Files\/View.php#1003","userAgent":"Mozilla\/5.0 (Linux) mirall\/2.3.3 (Nextcloud)","version":"13.0.1.1"}
@icewind1991 it was your patch, can you take a look?
tflidd
on 5 Apr 2018
The topic on the forum is still active:
https://help.nextcloud.com/t/files-become-zero-bytes/7214
I looked through my setup as well and found a lot of 0-bytes files. I have to hunt them down and check in older backups, if I can find the actual files again and perhaps find why this happened. Reopening.
tflidd
on 12 May 2018
I'm glad you reopened it, @tflidd - I've just redone a check and got 361 files set to 0. Some of the files being older than 1 year, so I'm not sure if the backup gods will go softly on me.
This is getting serious.
Upate: I just realized it's not _that_ dramatic - 312 of the zeroed files are in the ./data/updater-*/ folders. But still 49 files in Nirvana....
mikelupe
on 12 May 2018
Update after some research:
I must correct that I only really lost two files to 0 but was able to recover them from a backup.
These two files may be from an older sync executed with an old windows NC client around the end of 2016. The other 0-ed files were either really empty (text files not really used) or were in one of these directories, which didn't really bother:
Some files:
./data/appdata_50793ab339aa5/preview/16024/64-64-crop.png
./data/rainloop-storage/_data_/_default_/cache/c5/0c/c50c82f5bf4415357b97f23ab6deb16c6cd4d695
And some folders:
./data/user/files_trashbin/files/...
./data/appdata_ochidghtcad7/avatar/users/generated
./data/updater-*/...
So this may really be related to a problem we had with a much older windows client. Sorry for the alarmism from my side.
mikelupe
on 13 May 2018
This behavior comes when the initial upload is interrupted by errors. So i would suggest that after an upload the file size should be checked if it is the same size as the original file.
I always do this manually to be secure and unfurtunately i sometimes find files with zero file size after the initial upload by the Windows client, like as today again with client 2.3.3 and NC 13.04.
More details: https://help.nextcloud.com/t/files-become-zero-bytes/7214/19
Sanookmakmak
on 13 Jun 2018
I have this bug with some of my nextcloud users. Since some months, first report of a user in June. They use windows and/or linux clients.
We couldn't reproduce for now.
Server configuration
Operating system: Debian GNU/Linux 9 (stretch) - Linux 4.15.17-1-pve (proxmox container)
Web server: Apache/2.4.25 (Debian)
Database: mysql Ver 15.1 Distrib 10.1.26-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
PHP version: PHP 7.0.30-0+deb9u1
Nextcloud version: 13.02
Updated from: Nextcloud 12.? whith webgui installer
Where did you install Nextcloud from: Original clean manual installation of Nextcloud 9 (from nextcloud.com download) and then additionally migrated data from an old owncloud installation
Signing status:
Signing status
No errors have been found.
List of activated apps:
App list
Enabled:
- activity: 2.6.1
- admin_audit: 1.3.0
- admin_notifications: 1.0.1
- bruteforcesettings: 1.1.0
- comments: 1.3.0
- dav: 1.4.7
- federatedfilesharing: 1.3.1
- federation: 1.3.0
- files: 1.8.0
- files_automatedtagging: 1.3.0
- files_pdfviewer: 1.2.1
- files_retention: 1.2.0
- files_sharing: 1.5.0
- files_texteditor: 2.5.1
- files_trashbin: 1.3.0
- files_versions: 1.6.0
- files_videoplayer: 1.2.0
- firstrunwizard: 2.2.1
- gallery: 18.0.0
- groupfolders: 1.2.2
- logreader: 2.0.0
- lookup_server_connector: 1.1.0
- nextcloud_announcements: 1.2.0
- notifications: 2.1.2
- oauth2: 1.1.1
- ojsxc: 3.4.1
- ownpad: 0.6.6
- password_policy: 1.3.0
- provisioning_api: 1.3.0
- richdocuments: 2.0.10
- serverinfo: 1.3.0
- sharebymail: 1.3.0
- spreed: 3.2.5
- survey_client: 1.1.0
- systemtags: 1.3.0
- theming: 1.4.5
- twofactor_backupcodes: 1.2.3
- updatenotification: 1.3.0
- workflowengine: 1.3.0
Disabled:
- announcementcenter
- circles
- deck
- direct_menu
- encryption
- files_accesscontrol
- files_external
- keeweb
- ocr
- spreedme
- user_external
- user_ldap
Nextcloud configuration:
Config report
{
"system": {
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"***REMOVED IP VALUE***",
"***REMOVED URL VALUE***",
"***REMOVED IP VALUE***"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "13.0.5.2",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"forcessl": true,
"forceSSLforSubdomains": true,
"mail_smtpmode": "smtp",
"mail_smtpsecure": "tls",
"mail_smtpauthtype": "PLAIN",
"mail_smtpauth": 1,
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "587",
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"theme": "",
"maintenance": false,
"appstore.experimental.enabled": true,
"logfile": "\/var\/log\/owncloud.log",
"loglevel": 0,
"logtimezone": "Europe\/Paris",
"logdateformat": "Y-d-m H:i:s",
"skeletondirectory": "\/var\/www\/data\/skeleton_new_user",
"trashbin_retention_obligation": "auto,15",
"filelocking.enabled": true,
"updatechecker": false,
"memcache.local": "\\OC\\Memcache\\Redis",
"memcache.locking": "\\OC\\Memcache\\Redis",
"redis": {
"host": "***REMOVED SENSITIVE VALUE***",
"port": 6379
},
"activity_expire_days": 14,
"default_language": "fr",
"updater.release.channel": "stable",
"overwrite.cli.url": "https:\/\/partage.atd-quartmonde.org",
"knowledgebaseenabled": true
}
}
Are you using external storage, if yes which one: no
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Client configuration
Browser: any (firefox, chrome, chromium, internet explorer)
Operating system: ubuntu,windows
I will try the @icewind1991 patch to have logs.
nikosnikos
on 15 Aug 2018
... well, running find [nextcloud data directory] -size 0 -type f | grep -v updater | wc -l results in 3362 for me. this will be fun to sort out. If I might do any poking at my system to bring light onto this issue, let me know what might yield useful clues.
Here's my system report:
Server configuration detail
Operating system: Linux 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64
Webserver: Apache/2.4.29 (Ubuntu) (apache2handler)
Database: mysql 10.1.41
PHP version: 7.2.19-0ubuntu0.18.04.2
Modules loaded: Core, date, libxml, openssl, pcre, zlib, filter, hash, Reflection, SPL, sodium, session, standard, apache2handler, mysqlnd, PDO, xml, apcu, bz2, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, iconv, igbinary, imagick, intl, json, exif, mysqli, pdo_mysql, Phar, posix, readline, recode, redis, shmop, SimpleXML, sockets, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, wddx, xmlreader, xmlrpc, xmlwriter, xsl, zip, Zend OPcache
Nextcloud version: 16.0.4 - 16.0.4.1
Updated from an older Nextcloud/ownCloud or fresh install:
Where did you install Nextcloud from: upgrades since v.14 or so.
Signing status
Array
(
[core] => Array
(
[EXTRA_FILE] => Array
(
[.rnd] => Array
(
[expected] =>
[current] => 33bb71aa904b1f64c213c9d0c684192f616b5be54243f980a565661de87f22b01474d18f2ea63b4b71c40856cc244ea698878d1ac073b0a3c53d76dcb9f1bbba
)
)
)
[files_rightclick] => Array
(
[EXTRA_FILE] => Array
(
[README.md] => Array
(
[expected] =>
[current] => cf73849388838de5037624e53303618579b164ec69fd55834ce4c5332ae33f778839e36298cbcc8ede90620927e076dbb8883479754e4c09b0491b15bf7653f3
)
)
)
)
List of activated apps
Enabled:
- accessibility: 1.2.0
- activity: 2.9.1
- admin_audit: 1.6.0
- announcementcenter: 3.5.1
- bruteforcesettings: 1.4.0
- calendar: 1.7.0
- camerarawpreviews: 0.7.0
- circles: 0.17.7
- cloud_federation_api: 0.2.0
- comments: 1.6.0
- contacts: 3.1.3
- dav: 1.9.2
- deck: 0.6.6
- federatedfilesharing: 1.6.0
- federation: 1.6.0
- files: 1.11.0
- files_downloadactivity: 1.5.0
- files_external: 1.7.0
- files_markdown: 2.0.6
- files_pdfviewer: 1.5.0
- files_rightclick: 0.15.1
- files_sharing: 1.8.0
- files_texteditor: 2.8.0
- files_trashbin: 1.6.0
- files_versions: 1.9.0
- files_videoplayer: 1.5.0
- firstrunwizard: 2.5.0
- gallery: 18.3.0
- gpxedit: 0.0.11
- gpxmotion: 0.0.9
- gpxpod: 4.0.5
- groupfolders: 4.1.0
- keeweb: 0.5.1
- logreader: 2.1.0
- lookup_server_connector: 1.4.0
- metadata: 0.9.0
- nextcloud_announcements: 1.5.0
- notifications: 2.4.1
- oauth2: 1.4.2
- ocsms: 2.1.3
- ojsxc: 3.4.4
- password_policy: 1.6.0
- phonetrack: 0.5.2
- polls: 0.10.2
- previewgenerator: 2.1.0
- privacy: 1.0.0
- provisioning_api: 1.6.0
- quota_warning: 1.5.0
- recommendations: 0.4.0
- serverinfo: 1.6.0
- sharebymail: 1.6.0
- support: 1.0.0
- survey_client: 1.4.0
- systemtags: 1.6.0
- tasks: 0.11.1
- theming: 1.7.0
- twofactor_backupcodes: 1.5.0
- updatenotification: 1.6.0
- viewer: 1.1.0
- workflowengine: 1.6.0
Disabled:
- encryption
- end_to_end_encryption
- flowupload
- music
- richdocuments
- sensorlogger
- spreed
- user_ldap
Configuration (config/config.php)
{
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"[removed]"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"overwrite.cli.url": "[removed]",
"dbtype": "mysql",
"version": "16.0.4.1",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"logtimezone": "UTC",
"installed": true,
"maintenance": false,
"theme": "",
"loglevel": 2,
"memcache.local": "\\OC\\Memcache\\APCu",
"memcache.locking": "\\OC\\Memcache\\Redis",
"filelocking.enabled": "true",
"redis": {
"host": "***REMOVED SENSITIVE VALUE***",
"port": 0,
"timeout": 0,
"password": "***REMOVED SENSITIVE VALUE***",
"dbindex": 0
},
"htaccess.RewriteBase": "\/nextcloud",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtpmode": "smtp",
"mail_smtpauthtype": "LOGIN",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "3325",
"mail_smtpauth": 1,
"mail_smtpsecure": "tls",
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"mail_sendmailmode": "smtp",
"updater.release.channel": "stable"
}
External storages: yes
External storage configuration
No mounts configured
Encryption: no
User-backends:
- OCUserDatabase
Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
kr4z33
on 4 Sep 2019
On mine, the earliest 0's are 2019-04-14.
Some are in my "files_trashbin" folder, others are in "updater-ocfantherpmc". Many other 0 size files are sprinkled among my 200+ GB of user files, with no apparent pattern of location.
They seem to be in batches with similar changed dates, which leads me to think this has come from problematic syncs that occurred on those dates.
After I sift through the wreckage, I'll take a stab at setting up a minder script on the server to wave it's arms around when files of size 0 appear, to hopefully make some observations of what is happening in the system when these 0 files show up.
kr4z33
on 13 Sep 2019
Attempting to replace some zeroed files with backups, gets me into thje problem described below, this is with client v. 2.5.2 (build 20190309), and persisted through my upgrade to client 2.5.3 (build 20190725) :
Replace zero size file on windows machine with an actual nonzero file from a backup. Sync client apparently does not see the change. File remains zero size on server.
workaround is:
delete file on client computer -> client does sync, deleting file on server -> put backup file into it's place -> client does sync, file is restored in Nextcloud server.
Doing my due diligence, these reports might be related somehow:
https://github.com/nextcloud/server/issues/7995
https://github.com/nextcloud/desktop/issues/1323
kr4z33
on 14 Sep 2019
I made a babysitter to make noise when zero sized files show up in the NC data directory. I run the following via cron by an appropriately privileged user on my server every few minutes, on initial run, it makes a text summary of all the zero sized files in the nextcloud data directory for review, minus couple of things that are ignored that I found to make some false positives (trashbin files, portableapps program files from portableapps.com, updater files, and some __init__.py files). On subsequent runs it finds changes to the file list and sends emails with the summary of the new zero sized files. For the emailing it requires a working mutt program to be setup. The stuff that will be installation specific needing some fill in the blanks work are [redacted]
It made some noise on my system during some problematic internet service to the server that apparently interrupted some uploading from an android device. Upon repair by the ISP the issue was resolved by normal nextcloud operations.
#!/bin/bash
#this helps review new zero sized files in the nextloud data directory
#it will email a timestampted file of zero sized files found in the nextcloud directory with a diff output in the email body
#Ignored files include portableapps.com files, trashbin, updater, and __init__.py files
#This Script needs to be run as a user with access to the www-data group, to access the nextcloud Data directory
#echo lines for manual running/debugging are commented
reviewerEmail=[redacted]
serverEmail=[redacted]
NCdatapath=[redacted]
filepath=[redacted]
timestamp=$(date +"%FT%H%M%S")
#### With the above lines edited to suit, edits below should be unnecessary ####
# echo "$timestamp finding files..."
if [ -s ${filepath}master.NC.0.Files.txt ]
then # master is non-zero, moving on, assuming a list of zero files has been previously made & reviewed
find ${NCdatapath} -size 0 -type f -exec stat -c '%n | %s | %w | %x | %y | %z' {} + | grep -v PortableApps | grep -v trashbin | grep -v updater | grep -v __init__.py > ${filepath}${timestamp}.NC.0.Files.txt
# compare to a master list of zero sized files that has been reviewed
diff -u ${filepath}master.NC.0.Files.txt ${filepath}${timestamp}.NC.0.Files.txt > ${filepath}NC.0.Files.diff.txt
if [ -s ${filepath}NC.0.Files.diff.txt ]
then # diff file is non zero - get the humans involved
#echo "emailing..."
cat ${filepath}NC.0.Files.diff.txt | mutt -e "set from=${serverEmail}" -s "file for review" -a ${filepath}${timestamp}.NC.0.Files.txt -- ${reviewerEmail}
else # diff file is zero do not retain find result, do not disturb the human
rm ${filepath}${timestamp}.NC.0.Files.txt
#echo "${timestamp} & All's well" # no hell raised
fi
else # master file is zero size - first run, or missing master file fault requires human intervention
find ${NCdatapath} -size 0 -type f -exec stat -c '%n | %s | %w | %x | %y | %z' {} + | grep -v PortableApps | grep -v trashbin | grep -v updater | grep -v __init__.py > ${filepath}master.NC.0.Files.txt
#echo "emailing new master file for human check"
mutt -e "set from=${serverEmail}" -s "file list for review" -a ${filepath}master.NC.0.Files.txt -- ${reviewerEmail} <<< "These zero sized files were found, and will be assumed to be OK without intervention"
fi
#echo "Done."
I'll probably keep running this for a while until it gets annoying, so far it seems that incorrect zero sized file creation is actually a rare thing.
kr4z33
on 29 Oct 2019
OK, this is actually a bit scary. I just found this issue because I tried to upload a lot (~20k) of pictures through the iOS Client to my 17.0.2 Instance and it created thousands (!) of zero-byte files.
After finding out about this I looked for more. I found them all across my data-directory, across all users, across various versions of clients, across various operating systems. They seem to have one thing in common though: They appear in big bulk-sync operations.
Day-to-day syncing seems to work fine, but as soon as a lot of files get synced, some of them get truncated.
Subito
on 26 Jan 2020
Scary bug that I just experienced as well with the latest version of Nextcloud server/client :(
Nextcloud server version:
$ occ status
- installed: true
- version: 18.0.1.3
- versionstring: 18.0.1
- edition:
Nextcloud client:
$ nextcloudcmd --version
Nextcloud version 2.6.2git
Using Qt 5.13.2, built against Qt 5.9.5
Using 'OpenSSL 1.1.1 11 Sep 2018'
cyberang3l
on 16 Feb 2020
I'm seeing this issue also.
Server
- installed: true
- version: 17.0.3.1
- versionstring: 17.0.3
- edition:
Client
Nextcloud version 2.6.3git
Using Qt 5.9.5, built against Qt 5.9.5
Using 'OpenSSL 1.1.1 11 Sep 2018'
wrighrc
on 3 Mar 2020
I don't think this is the issue https://trac.cyberduck.io/wiki/help/en/howto/mount/issues/fastcgi#ZerobytefiletruncateissuewithNextcloudandownClouddeployedwithFastCGI but its seemed like a good candidate
apache2ctl -M | grep fpm
(nothing)
I see apache has https://httpd.apache.org/docs/trunk/mod/mod_policy.html
I wonder if PolicyKeepalive enforce would help (looks like default is ignore)
wrighrc
on 3 Mar 2020
cc @rullzer @nickvergessen @blizzz I don't like those last reports :confused:
Care to have a look?
skjnldsv
on 10 Apr 2020
Crossposting from the help forum:
I just hit the same issue, latest NextCloud running in Docker, with the latest Windows client.
I transferred a bunch of larger files amounting to ~130GB in total, and 2 of the larger files are 0 bytes. I got a bunch of 503 errors during upload in the client, so it restarted, 503 again, restarted, and so on for several hours. Finally finished, and now I’m left with 0 byte files.
jonasrosland
on 20 May 2020
Since the forum post is now closed and we should provide more info here, I'd be happy to provide any help to the developers to get this bug squashed. Just let me know what you need.
Server:
occ status
- installed: true
- version: 18.0.4.2
- versionstring: 18.0.4
- edition:
Client:
Version 2.6.4stable-Win64 (build 20200303).
jonasrosland
on 21 May 2020
This happened before, but now im 2 more installs in, and i have lost files now. 0 bytes. Anyone ever figure out whats going on?
Cronus89
on 20 Jun 2020
@Cronus89 I must admit the account concerned by this problem hasn't used a nextcloud windows desktop client anymore for quite a time, so this hasn't happen since. Maybe it was a Windows 7 problem. I still find some 0-files though, but it's mostly about updatefolders or old versioning files, so nothing super-critical.
mikelupe
on 20 Jun 2020
I was also seeing this same issue, when using the android NC client on my ChromeOS system, when copying files to the NC server using the ChromeOS file manager that includes the NC files as an additional directory, when the android app is installed on ChromeOS. This issue was only happening some of the time, and mostly when copying multiple files to the server at the same time.
I have since switched to using the web interface to NC in its own window, which works very well. I have had no cases of the zero byte files since using the web interface for file upload and management.
cshelton1409
on 20 Jun 2020
Not using/being able to use the NextCloud Desktop Client negates the reason for me to switch to it. I'm on Windows 10. And this seems like some odd issue thats never been resolved in years
Cronus89
on 21 Jun 2020
Curiously enough, I have files that show as 0KB but I can open them and view them both on my Mac and through the web interface and when I download the file, it shows the correct size again. I didn't bother at first, but some apps throw an error when they see the 0KB and refuse to open the file.
I used WebDav in Finder (Catalina 10.15.5) to upload and access files. Just now I read the warning for doing so in the handbook(accessing files using macOS through WebDav) and will not use Finder again.
We started using a self-hosted NextCloud instance on a server in our home during June 2020, so I assume we have a new version but I'm not the admin.
[UPDATE]
Since the files seem to exist despite 0KB being displayed, I tried and succeeded the following. I trialed Transmit and used the "Synchronize" feature. (1) Synced from NC to local all files (I tried it with one folder at first only). (2) Synced from local to NC, comparing files by size. It succeeded in now showing the correct filesize in Nextcloud (both, WebDav and Web interface).
[UPDATE 2020-07-07] Transmit failed when I tried to fix more than a few files at a time. It didn't work as the solution I was hoping for.
GeorgLink
on 27 Jun 2020
I can reproduce the situation mentioned by @GeorgLink quite easily. I am accessing Nextcloud over WebDAV from Gnome Online Accounts (note that I am not running the desktop client). When this share is mounted using GVFS, and I download a file directly to it from Firefox, it will show up as having a size of 0 bytes (both in the Nextcloud web interface and in the GNOME Nautilus file browser).
However, as @GeorgLink also pointed out, the file contents is there and I can open it just fine, it is just the file size that is reported incorrectly. In order to correct the situation I can simply move the (ostensibly) empty file to a local file system and back to the Nextcloud GVFS mount using Nautilus. At this point, it will show up with the correct file size.
Version/distro info:
tore@cloud:~$ lsb_release -d
Description: Ubuntu 18.04.4 LTS
tore@cloud:~$ sudo snap list nextcloud
Name Version Rev Tracking Publisher Notes
nextcloud 19.0.0snap1 21796 latest/stable nextcloud✓ -
toreanderson
on 7 Jul 2020
My issue is the opposite, where files (for a while after upload) are shown as full size, but when I try to download them they are 0 bytes. I could reproduce this by syncing several large directories with large files, through the client.
jonasrosland
on 7 Jul 2020
Howdy, was doing some testing trying to track down the issue and thought I would share what I've done. Our issue is that when using v19 and MacOS as the client, the file size of all uploaded files are 0bytes. Looking at the file stored it appears to be the correct size but the size in the oc_filecache table is still 0.
I'll be honest, I'm not familiar with the nitty-gritty details of webdav but I do understand that MacOS has a different implementation of webdav and first creates a file at 0bytes and overwrites the file with the real data. With that said I wanted to eliminate some things about this issue that I suspected. First I wanted to eliminate the environment being the issue. This is because the original cause of the problem was because of an issue with apache mods/nginx.
So, I used the nextcloud docker images as my base. nextcloud:production (apache php7_mod) works and image as of 2020/07/07 runs v17. While nextcloud:19-apache (php7_mod) which is v19, does not work. So I built the production docker image locally and verified that the built image works. And by 'works' I mean I am able to write files via webdav and have the size be correct.
My next test is to change the image so that instead of downloading the version 17 it would download version 19. So the end result of the image would be the environment of the working v17 running version 19. I checked the php versions and mod versions and poof it is exactly what I was looking for. If the problem was with the version of apache/php/os/whatever, then this image should of worked. Unfortunately the answer is no. v19 still did not work.
So I deduced that the issue MUST be in the code. First lets rule out Sabre (the webdav library) that nextcloud uses. I noticed in v17 we are using 3.2.3 while in 19 we are using 4.0.0. So I reverted to the older library and its dependencies. :/ still no go.
That tells me the issue is within the nextcloud code base and that the issue I am experiencing has the same symptoms as the issues with fpm or nginx but is now a code issue. I started diving deep in the code to log some debug data when all of a sudden it starts working in v19. So I added a single line to apps/dav/lib/Connector/Sabre/File.php
240c240,241
< }
---
> }
> \OC::$server->getLogger()->log(5, 'This makes no sense to why adding this line fixes my issues' , ['app' => 'MikeDebug']);
Im not too familiar with the codebase so I am not sure exactly what is executed in \OC::$server->getLogger()->log that would correct the issue. This is where I'm at and need to take a break from this before my head explodes.
mike-link
on 7 Jul 2020
I am having the same problem with V19. I tried to validate if adding that line would solve the problem for our systems, but I am not a developer and I didn't know where in the file to add the code. If you let me know I can try it on our two installations that have this problem.
bbolokofsky
on 8 Jul 2020
Same Problem when using "RAIDRIVE" as a client under Windows 10.
Server: Latest snap-Version (19.0.0).
theoneandonly-vector
on 17 Jul 2020
We have run into this issue this week on the latest stable V19, it does seem to be tight to a single user. This has happened in the past but never where able to pin down the actual cause.
When restoring the file from Versions it immediately jumps from xx kb to 0 bytes. When opened in Onlyoffice it is empty, when downloaded the content is there. We restore, download, delete and upload to recover these files.
This has been one incident so far with +- 10 office files in the same root folder. They all zero-ed around the same time, we suspect a sync client because of this. We are monitoring the NC data directory now for new 0 bytes files to catch any new incidents quickly.
Edit: Around the same time the files got zero-ed we had license exceeded warnings from OnlyOffice. This could have caused it in our case, I have not yet tried to reproduce. I am talking OO about this as we have support from them.
mvvvmd
on 10 Sep 2020
The single user is probably running into an issue with using the Mac Finder
as their client to connect. Until this is fixed for good I would recommend
that you ask them to use a different client. We have been using Mountain
Duck with no issues. For the files that already have an issue, there is a
command line tool called occ run the command occ files:scan [user_id]
and it should fix the problem with the existing files. The occ command is
a php file so depending on your setup you might need to run something like
sudo -u www-data php occ files:scan [user_id]. Here are the docs for that
https://docs.nextcloud.com/server/19/admin_manual/configuration_server/occ_command.html?highlight=occ#file-operations-label
On Thu, Sep 10, 2020 at 4:58 AM Machiel van Veen notifications@github.com
wrote:
We have run into this issue this week on the latest stable V19, it does
seem to be tight to a single user. This has happened in the past but never
where able to pin down the actual cause.When restoring the file from Versions it immediately jumps from xx kb to 0
bytes. When opened in Onlyoffice it is empty, when downloaded the content
is there. We restore, download, delete and upload to recover these files.This has been one incident so far with +- 10 office files in the same root
folder. They all zero-ed around the same time, we suspect a sync client
because of this. We are monitoring the NC data directory now for new 0
bytes files to catch any new incidents quickly.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/server/issues/3056#issuecomment-690125885,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOS746JZ6QBELKHKJ722WUDSFCPNJANCNFSM4C4JMZJQ
.
mike-link
on 10 Sep 2020
The single user is probably running into an issue with using the Mac Finder as their client to connect.
I confirmed with the user they are not using the sync clients, the likely cause is still OnlyOffice in this case. However I can't be 100% sure about that. I will attempt a file:scan instead of restoring versions if this happens again. I have a daily check on 0 byte files running now.
mvvvmd
on 16 Sep 2020
This so extremly annoying (mikelupe opened this issue on 13 Jan 2017)
-> Using Hansson IT Installation
-> Updated to 19.03
-> Using MountainDuck 4.2.0 *
MountainDuck runs into the Issue if the Connection-Mode is set to "Online"
MacOS runs into the Issue when using Finder
My problem is a bit more extreme, because the Files on the Storage are also 0kb - means a data loss.
Could maybe a Nextcloud Developer (@nextcloud-bot @MorrisJobke @rullzer) or somebody else do a statement?
If this is not addressed / fixed I have to come up with another solution for my environment.
Best Regards
Max
- we need to run an additional software as the NextCloud Client is not an option on a Terminal Server as it still hasn't the Online-Only Mode.
MaximilianOnGitHub
on 16 Sep 2020
My problem is a bit more extreme, because the Files on the Storage are also 0kb - means a data loss.
Forgot to mention in our case the files on disk are 0 bytes also, we do have versions with data but changes are lost. Very bad for user trust.
mvvvmd
on 16 Sep 2020
Chiming in here, this happened to me, too, During the Processes of syncing a large amount of photos over a flaky connection. I also got some conflicts that didn't really exist.) Hopefully, it really "just" caused 0 byte files, because those where easy to find and restore from snapshots. I will certainly run a service now to notify me about 0 byte files.
Still, this is VERY concerning, and if there was a proper alternative (I don't consider Seafile one mainly because it does not store the data as files), I would change now.
kvoit
on 5 Oct 2020
I've modified the script posted by @feisar
I had a lot of zero byte files (unrelated to this), and could not easily see what files may be affected.
This outputs each item on a new line, and cuts out the path before '/user/files'
I'll be monitoring with a cron job moving forward as I almost lost irreplaceable data, luckily I had a recent backup.
#!/bin/bash
filesystems[0]="user1/files"
filesystems[1]="user2/files"
cd "/nextcloud/data/folder/"
emAdy="[email protected]"
emSub="Warning: Nextcloud Contains 0 Byte Files"
for fs in "${filesystems[@]}"; do
while read -d '' -r; do
arr+=( "$REPLY\n" )
done < <(find $fs -size 0 -print0)
done
if [[ ! -z ${arr[@]} ]]; then
echo -e ${arr[@]} | mail -s "$emSub" "$emAdy"
fi
Wdavery
on 6 Oct 2020
I'm coming here after syncing a large amount of files to a new Nextcoloud 19 instance with the latest Ubuntu client, and I'm seeing the same issue. BUT it's important to note that it's not _just_ zero byte files. I have PDFs that are 425bytes on the desktop and 32 on the server. Corrupted.
Digging into this it appears there were errors not being able to check the chunks on upload which cause 500 errors, but the client never retries the files and considers them 'in sync' when they are clearly not. This is a pretty huge issue. Manually uploading them through the web gui gets things back in sync, but I pushed up 6000+ files.. :-1:
Routhinator
on 31 Oct 2020
Dears,
i have the situation that the files are in S3 and i am checking against the bucket (selecting all files that are 0 bytes) and then get the file path out of oc_filecache. with this i found a folder where files were uploaded 7 years ago, only 2 files in that folder were corrupt and those had an age of 2 years, it seems as if the corruption took place long after the upload
The problem occurs in a lot of different configuration, stable and fast network connections, also slower and unstable ones.
Windows, Linux and Macos, thoughout all nextcloud version that we had installed (o would say 10 through 19) amd with several different client version from the last years.
to me my comment here does not seem very helpful, but maybe there is something in here that helps someone figure this out.
We will continue to watch the issue and report if we find something
cheers
soeren
smalchow
on 7 Nov 2020
Dear all,
i have some more information.
I was working on exactly finding out what happen with a specific file that was 0 bytes.
That file was uploaded on Nov. 5th by user A (Windows 10, Nextcloud 3.0.2 client), during the upload there was an error because nextcloud could not find the clamscan binary (happend with files that are just fine as well though)
After that i could see these two log messages:
failed to open stream: HTTP request failed! HTTP/1.1 416 Requested Range Not Satisfiablern at
"message":"fopen(httpseek://): failed to open stream: "OC\Files\Stream\SeekableHttpStream::stream_open" call failed at
On Nov 6th another user could not synch the respective folder (Windows 10, Nextcloud 3.x client, could not get the version right now), that user deleted the file in the Webfrontend.
During the weekend, i fixed the anti virus configuration (not sure if it is important, but i want to be complete).
This morning, User B (user who deleted) reported the file being "back" and complete, and user A (original source) also still has it correctly.
I check in the database in "oc_filecache" there are 2 files of that name (or similar in case of the trashbin) one file is correctly where it should be and one file is in the trahsbin with 0 bytes
<-- snip -->
+---------+---------+-----------------------------------------------------------------------------------------------------------------------------+----------------------------------+---------+---------------------------------------------+----------+----------+--------+------------+---------------+-----------+------------------+---------------+-------------+----------+
| fileid | storage | path | path_hash | parent | name | mimetype | mimepart | size | mtime | storage_mtime | encrypted | unencrypted_size | etag | permissions | checksum |
+---------+---------+-----------------------------------------------------------------------------------------------------------------------------+----------------------------------+---------+---------------------------------------------+----------+----------+--------+------------+---------------+-----------+------------------+---------------+-------------+----------+
| 8487363 | 208 | XXX.pdf.d1604681511 | 355588f474a8357b7899109eb5566ab9 | 82067 | XXX.pdf.d1604681511 | 7 | 3 | 0 | 1604600616 | 1604600616 | 0 | 0 | 5fa4432e5ee44 | 27 | NULL |
| 8488913 | 208 | XXX.pdf | 14388e1f9024a4cc6e9015df633d37b6 | 8308416 | AWS_CB_NX_1322291823_202010.pdf | 7 | 3 | 290474 | 1604600653 | 1604907666 | 0 | 0 | 5fa8f29289e5a | 27 | NULL |
+---------+---------+-----------------------------------------------------------------------------------------------------------------------------+----------------------------------+---------+---------------------------------------------+----------+----------+--------+------------+---------------+-----------+------------------+---------------+-------------+----------+
2 rows in set (15.58 sec)
<-- snip -->
looks like this, neither of the users interfered with that file inbetween, it was restored/reuploaded without manual intervention.
I grepped the interesting line out of the logfiles and i have a lot more information on 0 byte files and often we have that.
I can share that with a developer who is working on that, but it is very hard to anonymize the data, thats why i can not share this publicly.
Cheers
Soeren
smalchow
on 9 Nov 2020
Related issues
MorrisJobke
·
3Comments
williambargent
·
3Comments
dl5rcw
·
3Comments
j-ed
·
3Comments
e-alfred
·
3Comments
Most helpful comment
Howdy, was doing some testing trying to track down the issue and thought I would share what I've done. Our issue is that when using v19 and MacOS as the client, the file size of all uploaded files are 0bytes. Looking at the file stored it appears to be the correct size but the size in the
oc_filecachetable is still 0.I'll be honest, I'm not familiar with the nitty-gritty details of webdav but I do understand that MacOS has a different implementation of webdav and first creates a file at 0bytes and overwrites the file with the real data. With that said I wanted to eliminate some things about this issue that I suspected. First I wanted to eliminate the environment being the issue. This is because the original cause of the problem was because of an issue with apache mods/nginx.
So, I used the nextcloud docker images as my base.
nextcloud:production(apache php7_mod) works and image as of 2020/07/07 runs v17. Whilenextcloud:19-apache(php7_mod) which is v19, does not work. So I built the production docker image locally and verified that the built image works. And by 'works' I mean I am able to write files via webdav and have the size be correct.My next test is to change the image so that instead of downloading the version 17 it would download version 19. So the end result of the image would be the environment of the working v17 running version 19. I checked the php versions and mod versions and poof it is exactly what I was looking for. If the problem was with the version of apache/php/os/whatever, then this image should of worked. Unfortunately the answer is no. v19 still did not work.
So I deduced that the issue MUST be in the code. First lets rule out Sabre (the webdav library) that nextcloud uses. I noticed in v17 we are using 3.2.3 while in 19 we are using 4.0.0. So I reverted to the older library and its dependencies. :/ still no go.
That tells me the issue is within the nextcloud code base and that the issue I am experiencing has the same symptoms as the issues with fpm or nginx but is now a code issue. I started diving deep in the code to log some debug data when all of a sudden it starts working in v19. So I added a single line to
apps/dav/lib/Connector/Sabre/File.phpIm not too familiar with the codebase so I am not sure exactly what is executed in
\OC::$server->getLogger()->logthat would correct the issue. This is where I'm at and need to take a break from this before my head explodes.