Closed mikelupe closed 1 year ago
Thanks for the detailed report!
Is there anything in the nextcloud.log or in your apache/nginx error.log?
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...
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
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 - 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
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 :-(
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
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 :)
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.
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?
Can you post those two lines? The GET and the PUT?
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":"--"} ...
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
No feedback since half a year. I will close this. Once you have more details we can of course reopen this ticket.
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.
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"}
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.
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
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".
@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.
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?
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.
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....
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.
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
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.
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:
List of activated apps:
Nextcloud configuration:
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
Browser: any (firefox, chrome, chromium, internet explorer)
Operating system: ubuntu,windows
I will try the @icewind1991 patch to have logs.
... 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.
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.
External storages: yes
Encryption: no
User-backends:
Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
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.
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
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.
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.
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'
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'
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)
cc @rullzer @nickvergessen @blizzz I don't like those last reports :confused: Care to have a look?
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.
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
Client: Version 2.6.4stable-Win64 (build 20200303).
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 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.
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.
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
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.
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✓ -
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.
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.
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.
Same Problem when using "RAIDRIVE" as a client under Windows 10. Server: Latest snap-Version (19.0.0).
Steps to reproduce
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 - mail - user_external - user_samlThe 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
```Client configuration
Browser: Firefox 50.1.0 Operating system: Debian 8.6 KDE Plasma / Windows 7
Logs
Web server error log
Web server error log
``` Errorlog from when? ```Nextcloud log (data/nextcloud.log)
Nextcloud log
``` Nextcloud log from when? ```Browser log
Browser log
``` From when?```