FIles 0 bytes after opened

ℹ️ Support
1

Hello,

We have had a interesting issue today, files where being emptied in a specific share once opened. The owner of the directory could open files fine. These where office files but also images, they would go to 0 bytes after opening.

I noticed a trailing space in the top directory name and I’ve unshared and renamed it and shared it again. It seems to work now. Nothing in the logs, NC fully up to date.

Has anyone else had this happen, is this perhaps a known issue?

2

Some more info, the incident still seems to be over, however I’m not sure. It is hard to separate user error and other issues from the files being emptied by whatever the issue is. I’m more doubtful the trailing space was the actual problem now.

I do want to get to the bottom of this considering the repercussions of this happening more often. The NC instance is used by a 100+ user NGO and we have a hard time getting people of random cloud services and on NC as it is. The team hit by this issue was on a deadline for a big event and the file content getting deleted has caused considerable stress and breaking of trust in the application.

So, what I found so far, hopefully something described here rings a bell with someone.

  • The issue seems to be limited to one shared folder.

  • I think just one user opening files triggered the issue. This user would open any file, docx, odt, jpg and it would be cleared of its contents. I have logged in as this user and have experienced the same problem.

  • I have seen files going to 7 kb and 0 kb, both would have no contents.

  • Recovering old version would usually work but the files could still be damaged, OnlyOffice would not open the in at least one occasion. It could be opened in Libreoffice after downloading. Possibly a separate issue.

  • I have recovered files from our backup system up to 14 weeks ago to get a non-empty version of the file.

  • I had enabled Redis locking caching the day before the complaints started. I have disabled it but am unsure if this was the actual cause as empty files exist from before this.

  • Restore from versioning was broken because of the Redis cache, when choosing restore it would through a locking error without fail.

  • We are using OnlyOffice.

  • Most of the users are in LDAP.

  • About 15 users where working in the shared folder.

  • The logs reveal no cause, I’ve chased every error in every log on all servers involved.

  • About 10 files have been affected so far.

Many thanks for any insight on this in advance.

3

The ultimate pointer would be if you can reliably reproduce the issue (then it is certainly a candidate for a bug report at Issues · nextcloud/server · GitHub).

Isolating issues won’t be easy I guess.

Is this folder shared by a specific user compared to other shared folders? Is it reshared?

Mostly office but not only. You spoke of an image affected as well, was it changed at some point? Or were the files moved around (when perhaps someone else edited them)?

When you didn’t use redis, the file locking was done in your database. Perhaps you kept the old locking table that caused the issue. Should be oc_file_locks or similar. Is this table empty and if not are the files concerned on it? And if you have backups from before, it would be interesting to look at this specific table.
Normally the problems should be less this file locking cache on redis…

This was the name of the shared folder creating these problems? Trailing white spaces created problems with syncing on Windows: Trailing Whitespace Directory breaks Nextcloud Sync and Windows Explorer · Issue #5843 · nextcloud/server · GitHub
Are any of these folders synced by users with a desktop client?

Do you use a current version, it’s just to avoid that you chase an old already known and fixed bug.

4

Thanks for your reply, I have not been able to reproduce the issue after it stopped happening. That would make a bug report possible indeed.

The only unique thing I could find with the shared folder was the trailing space., Resharing is common, the user sharing does this a lot.

As far as I can tel the files where just opened an they would revert to 0 bytes. I did think Onlyoffice was opening them as if empty and then overwriting them as empty. However it does not seem to be the case, also because I found empty image files I needed to restore. Onlyoffice does do this btw, I have a file that appears empty in OO but not in Libre.

I did not clear the locking table, that could at least explain the issue with restoring files. I’ll check the backups of that day, we have these for some months.

I did see that report making me suspect the trailing space. Trailing spaces are all sorts of terrible in file/dir names. Some users have NC sync on Linux so it could be a cause. Luckily we have eliminated Windows for all but three systems on our network, oss ftw :slight_smile:

We use the most current version, I try to update fairly quickly.

I think I’m going to setup a test system to figure these things out, try to reproduce. I’m also upgrading OO this weekend to 5.3 and do some more digging on the production system, thanks again so far.

5

I’m back from vacation and started testing the issue. I have been able to produce some of the issues when sharing a folder with a trailing space.

  • I need to name the folder on the local file system with a trailing space and sync with the desktop client. The web client does not seem to allow trailing spaces.
  • I had trouble sharing the folder at some point, the user list would not load.
  • The user who had the folder shared cannot open images any more, the owner can.

I suspect OnlyOffice does not like the situation either and opens the file blank then saves it. I’ll try and test this also.

6

I have not been able to reproduce the issue exactly, it has not happened again on production anymore either.

I’ve setup a script based on one posted in a bug report. It checks and corrects folder names with trailing spaces.