Nextcloud deletes my files on server every few hours

Nextcloud version (eg, 12.0.2): 14.0.4
Operating system and version (eg, Ubuntu 17.04): Linux kernel 4.14.67 - that’s all I know: it’s a VPS.
Apache or nginx version (eg, Apache 2.4.25): 2.2.22
PHP version (eg, 7.1): 7.0

The issue you are facing:
I installed Nextcloud, uploaded files using the web interface, and some of them delete themselves every day since installation. I restore them from trash and then they delete themselves again. This happens as often as I care to restore the files. Sometimes they delete themselves while I’m editing them.

I have only a few files store on there, in directories: to-do lists and ebooks, as well as the usual default directories. Only to-do lists gets deleted every day. ebooks directory gets deleted occasionally, but not always. FWIW to-do lists directory was added two days after ebooks directory.

Background/general info: I’ve had Nextcloud for a week as a FOSS alternative to G-Drive. I had an installation of Nextcloud 9.x in the same location since that was released, but had not logged in since installing it, as I didn’t need it and didn’t have time to play with it. I deleted the old version before installing the new, as per the installation walkthrough suggested.

I installed the nextcloud apps on my phone and tablet, but they were unusably unresponsive and slow, so removed them and use the web interface only, which has been fine. I thought the deleting may have been some kind of sync error with the apps or something, but it continues even now that I’ve deleted them.

Solutions and help very welcome.

Is this the first time you’ve seen this error? (Y/N):
First time I’ve used Nextcloud.

Steps to replicate it:

  1. Just log in and the disaster’s waiting for you.

The output of your Nextcloud log in Admin > Logging:

Unfortunately I don't know where to locate that as I don't know how to use Nextcloud and the manual wasn't clear on it.

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

$CONFIG = array (
  'instanceid' => 'xxxxxxxxx',
  'passwordsalt' => 'xxxxxxxxxxx',
  'secret' => 'xxxxxxxxxxxxxxxx',
  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => '',
  'datadirectory' => '/home/xxxx/',
  'dbtype' => 'sqlite3',
  'version' => '',
  'overwrite.cli.url' => '',
  'installed' => true,

The output of your Apache/nginx/system log in /var/log/____:

I don't appear to have access to this on my server. 

You can find this under the Admin Heading, then search for Logging in the left-hand menu.

You can find this easily with a terminal and if you suspect RPM based Linux, cat /etc/redhat-release or on Ubuntu and derivatives I believe it is cat /etc/os_release to find your Linux flavour.

Back to the Nextcloud log. Let’s assume you are running Ubuntu (which from the kernel version seems likely) you can find your NC log under /var/www/nextcloud/data/nextcloud.log IIRC. Without the log we won’t be able to help much. I have never seen this behaviour in all my installs of NC.


Hey Starfish, thanks for your quick reply.

/etc/os_release doesn’t work, but a poke around online suggests my host company is using Ubuntu 14, which sounds about right. (Possibly that version of Ubuntu predates /etc/os_release being used? )

I don’t have nextcloud log under /var/www… which is because Nextcloud is installed in userland, not system wide.

I did, however, find the log from the menu - an error appears every second:


Error PHP You are using a fallback implementation of the intl extension. Installing the native one is highly recommended instead. at /home/xxxx/ 2018-12-03T17:43:46+1100

I don’t know what that means, but getting one every second doesn’t sound good.

This means you are missing the PHP intl module. You will need to run something along the lines of

sudo apt-get install php7.0-intl

See if that helps?
After you have installed this, you need to restart your apache for it to take effect.

For the benefit of other experiencing the same issue, I’m with Dreamhost.

Unfortunately, I’m don’t have root access to install new packages.

However, I followed Dreamhost’s instructions on how to enable the intl extension, which it says is compiled but disabled by default. I did so for php7.2, which I had selected as the php version during my installation of Nextcloud.

During that process I checked my running processes and discovered that despite having selected to have php 7.2 my php version of choice, I was actually running 5.6! I killed the process, which restarted as 7.0. rather than 7.2. I just went with the flow and edited the phprc file for 7.0. restarted it - and lo, the stream of bugs stopped.

I’ll restore my files and see if Nextcloud can resist deleting them over the next few days before I mark this as solved. At the least we’ve fixed that one problem! I reckon maybe the mobile apps will work better now that log isn’t filling up with error messages every 0.5 seconds.

Thanks for your help, Starfish! Couldn’t have got this far without you.

I did nothing. Sorry for not knowing you did not have root access. I have a VPS service with Tilaa, and there I have root access together with a managed service pack.

Glad you were able to get it up and running though. I don’t know if the deletion is part of the intl package issue. As I have mentioned, have not seen this behaviour before. If you are able at all, just to test, maybe try and install the same setup on a Virtualbox VM and see if the behaviour is the same? There might be a problem with a layer in the VPS itself. Just a thought.

No luck. It’s still deleting the files.

We’re gonna need those logs then. Any idea if/how you can get to them? Maybe put in a request to your hoster service to give them to you? Without the logs we are pretty much flying blind. You could also bump the logs in the UI to debug, in order to get more verbosity?

It’s installed in my account, not system-wide, so the logs won’t be at /var/… they’ll be somewhere else. I installed this as my user from the zipfile.

Or they’ll be non-existant, but I think they’ll be under the nextcloud directory… I’ll have a fish around.

There’s a log file at data/nextcloud.log

The only things in it are the error messages from many hours ago relating to the intl problem. The files have since been deleted, so there’s nothing in the log relating to this.

Try to find the logs related to your issue, perhaps you need to enable debug logs first via config.php or logging app in admin settings. The intl module related logs are indeed a bid annoying and spamming log file. I hope something can be done to handle them better:

I just found out you can download the logs via web UI. So set your loglevel to debug, and wait for files to be deleted, then download the logs and attach them here so we all could help you look.

Thanks again for your persistence.

Setting the log to ‘debug’ reveals there is nothing in the log but the error messages relating to intl. The log is otherwise completely empty, so there is nothing to post.

It occurs to me that this is related to my personal account that is deleting files (let’s call it ‘melon’) not being an admin account. To get log files I have to log out from melon and into admin, because melon doesn’t have their own log, and the admin doesn’t log what happens to cause melon’s files to be deleted. I made a user account following the age-old wisdom that you should never use an admin account for anything other than admin.

Yesterday I installed a fresh copy of nextcloud in an entirely different directory on my vps, made from the same sha256 verified zip file as this troublesome one, and am pleased to note nothing has gone amiss in terms of files being deleted. It’s running perfectly smoothly.

I can only conclude something very, very wrong has happened with this one, and what that is there may not be any way to understand what that was.

I thought it may have been related to the nextcloud mobile app on my phone, which I had installed when I put nextcloud 9 on the server and then never used it. As I deleted NC9 and put NC14 over the top with the same users, I thought this may have confused the mobile app (which I’d forgotten was even installed on my phone) which may have caused sync errors that sent NC14 into this weird spiral. But on reflection, even though the two installations had the same server location and usernames they can’t have had the same passwords as the new installation’s password references a personal event that occurred since that NC9 installation.

This is a real headscratcher.

You are referring to your server here? So you “upgraded” from 9 to 14 directly? Using the same database etc?

I deleted 9 entirely, having not used it for year(s) and installed 14 from the zip.
I don’t quite follow what you mean by ‘same database’ - I deleted everything to do with 9 before installing 14.

In other news, the new installation won’t let me delete, rename or move one single text file, while everything else seems to work fine.

It’s a better problem to have, for sure.

This read as “I deleted 9 entirely, but kept the database part to make sure the previous files and users are still available in 14”. So what I thought was you installed 14 after deleting 9, but connected the 14 instance to the same database as the 9 instance was using, which is what one normally does if you upgrade. That would have broken a lot of things. But if you created a completely new database as well, but just added the same users, that is different.

What do you mean? Did you create a new text file, and now it won’t let you rename, delete or move it? Did you create it with and admin user and trying to do the edits as non-admin or what? A bit more info would be helpful, and also, the logs would help a great deal here.

Hi @Melon

Just to rule out that probable cause, you didn’t setup any file retention, did you?
As admin user under “Settings” you can find “Workflow” on the left hand side and there you can define automated deletion of tagged files/ folders:

Automated deletion of files would happen in combination with automated tagging then.