Repository navigation
Files getting set to 0 in data folder #3056
Description
Activity
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 fHere are some more users of Nextcloud with that zero bytes bug:
https://help.nextcloud.com/t/files-become-zero-bytes/7214For one of the users it could have been the client which overwrites the file:
https://help.nextcloud.com/t/files-become-zero-bytes/7214/3Does 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 2Kernel (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/LinuxWebserver 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.2PHP 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 TechnologiesGreat. 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).mp3php 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?
68 remaining items
I was using MountainDuck (CyberDuck).
So seems like MountainDuck (CyberDuck) isn't compatible with Nextcloud then?
After going through troubleshooting it seems its to do with the configuration on the server.
https://trac.cyberduck.io/wiki/help/en/howto/mount/issues/fastcgi
"Using a client to upload files with HTTP chunked transfer encoding to a server with fastcgi/php-fpm enabled can lead to zero-byte files"
"Using a client to upload files with HTTP chunked transfer encoding to a server with fastcgi/php-fpm enabled can lead to zero-byte files"
Yeah, I've seen that before.
To be able to use MountanDuck you need to change to Apache PHP. I'm quite surprised the MountainDuck devs haven't worked around this issue yet.
So it seems my client is causing this issue?
It seems that this is a combination of PHP-FPM, some clients and special conditions. Since a few months I'm monitorring this issue. At that time I had multiple zero byte files on all accounts, the reasons were not clear. Different clients were used. Some affected files were only edited on the desktop with the Linux/Windows clients, not on cell phones.Since april, I just had zero byte files on one account. The affected files were uploaded using the NC Android app with the auto upload function. At least my own NC account contains a lot of files in different sizes. A part is also encrypted with Cryptomator. However, there are no 0 byte files any more. The reason is unclear.
You can work around this by setting
fastcgi_request_buffering on. This may decreases the performance a bit and requires more memory, especially on larger files, since the data between nginx and php is buffered at nginx instead of just passing it through. Or use a PHP stack withput FastCGI, like Apache with its module, as already suggested.fastcgi_request_buffering on
To be clear, that's an Nginx settting.
- We still struggle with zero byte files using mountain duck. A couple a week across my client base (primarily with pdf files). We don’t have the problem with native windows WebDAV client. We are using an Apache reverse proxy to a docker Apache mod_PHP Nextcloud. We have put tickets in with mountain duck but after reviewing the logs they have no answers.…________________________________ From: Daniel Hansson ***@***.***> Sent: Friday, July 23, 2021 3:31 AM To: nextcloud/server Cc: bbolokofsky; Comment Subject: Re: [nextcloud/server] Files getting set to 0 in data folder (#3056) fastcgi_request_buffering on To be clear, that's an Nginx settting. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#3056 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH5OEDMYQ24FNL4FBGN3ZQTTZFADNANCNFSM4C4JMZJQ>.
I was affected by this issue, too, and after too many hours of searching for a solution, I found this issue report:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57087
It basically says to update Apache to 2.4.47+ and add "SetEnv proxy-sendcl 1" to Apache's virtual host directive.So I did exactly that (by using Ondřej Surý's PPA) and bingo, no more zero byte files when using Mountain Duck to copy files to Nextcloud.
Can anybody confirm this works on their end, too?- Tech and Me's Nextcloud VM 22.2.0
- Apache 2.4.51
- PHP 7.4.3 FPM/FastCGI
- Mountain Duck 3.4.0
Reacted by tfliddReacted by enoch85Reacted by jazzinaI have the same issue, when I upload PDF files via the Webbrowser (Firefox on Mac). Even PDFs I uploaded minutes ago, I cannot open any more.
When I open the file I get this error.
But the file in the files folder shows me still the correct size:
NC version: 22.2.3
Environment: docker apache imageEdit: It seems, that only files I recently uploaded are affected. File, which are older than 23 days, are not affected at all. So it seems, this "bug" was introduced with the Version 22.2.2 (or 22.2.1).
Reacted by DMW007Hi, please update to at least 23.0.12 and report back if it fixes the issue. Thank you!
@Zealot2000 thanx for solution, but in my case this wasnt enought.
second part of solution - fixing nginx reverse proxy (in my case) by adding following lines to nginx config:
client_max_body_size 50000M; client_body_buffer_size 400M;as described here
Reacted by Zealot2000
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:
Disabled:
The content of config/config.php:
Config report
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
Errorlog from when?
Nextcloud log from when?
From when?```