FYI - 17.0.1 may have re-introduced the "Cypress" Bug

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face: is for home/non-enterprise users. If you’re running a business, paid support can be accessed via where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:


Or for longer, use three backticks above and below the code snippet:


Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 12.0.2): 17.0.0
Operating system and version (eg, Ubuntu 17.04): Not entirely sure of distro (ISP hosting), but the kernel version is 2.6.32-954.3.5.lve1.4.66.el6.x86_64, so it looks like it might be “Deep Security 10.0” or “Deep Security 11.0” (Just a guess, though)…
Apache or nginx version (eg, Apache 2.4.25): 2.4.41
PHP version (eg, 7.1): 7.2.7

The issue you are facing:
An attempt to log in yesterday resulted in a message indicating an update was pending. The update proceeded, but reported “An error occurred.” directly after a step notification of “Repair step: Cleanup cypress files from viewer app”

Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it:

  1. Unable to do so as entire instance now locked in maintenance mode
  2. Suspect it can be induced by attempting to log in to an instance running 17.0.0

The output of your Nextcloud log in Admin > Logging:

Unable to provide as unable to access site at all

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

$CONFIG = array (
  'instanceid' => '{{ instance value }}',
  'passwordsalt' => '{{salt value}}',
  'secret' => '{{ secret value}}',
  'trusted_domains' => 
  array (
    0 => '{{ site URL}}',
  'datadirectory' => '{{ instance-related path data }}/nc/data',
  'dbtype' => 'mysql',
  'version' => '',
  'overwrite.cli.url' => '{{ site URL }}',
  'dbname' => '{{ site }}_NextCloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => '{{site identifier}}_NextCloud',
  'dbpassword' => '{{Database Password in plaintext}}',
  'installed' => true,
  'maintenance' => true,
  'mail_from_address' => 'nc',
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_domain' => '{{Domain Name}}',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtphost' => '{{ISP Mail Gateway}}',
  'theme' => '',
  'loglevel' => 0,

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

ISP hosted instance - unable to access that... 

When I saw the error for the first time, there was a message asking for the page to be refreshed, so I did as requested. I saw the same result.

Before doing anything else, I then performed Google search for the error message and found the thread here that discusses the issue relating the Cypress from the 16.0.1 release. (Note, this is a recent, clean, installation, that used the 17.0.0 zip file).

I have checked used my FileZilla client to check the /apps/Viewer/ folder and I do not find any references to Cypress related files. In fact, my /apps/viewer/ folder contains:-


and that’s it.

Very happy to provide further triage information if that would be of any help. I also note that I am unable to access the site via any means now and am not just being blocked by the GUI authentication page - i.e. WebDAV drive mapping from a Linux workstation is also failing. (Which stands to reason).

1 Like
{{ instance-related path data }}/nc/data

Have you checked nextcloud.log in above folder?

Hello Daniel,

I had not… I am sorry if this was an obvious step - I am new to NextCloud and I didn’t know to look.

I have just retrieved the file to my local workstation. It is pretty chunky - some 221.8kb…

Looking in the file, I can find the last message that I saw from my browser, relating to the “Repair Step: Cleanup cypress files from viewer app”, which occurred at 20:29:06 UTC. The next message is an error, which reads, “Error while sending QUERY packet”, that took place at 20:30:51 UTC and which appears to be attempting to access:-


That PHP file does exist in my site filetree and it has a timestamp of my original installation.

Does that help provide any further clues? I have downloaded a copy of the log file to my local workstation if further information is needed.

Thank you!

Are you able to access the instance via ssh? If no probably ask the isp to fix the setup.

=> false for maintenance mode off. But probably a bad idea with a incomplete update. Make a backup just in case :wink:

I do have SSH access to the site… at least, I’ve accessed via SSH to my hosting space before. But just to be clear… My ISP does not support NextCloud, so to get it installed and working, I had to download the zip file to my local machine, expand that archive, then ftp the contents across to my hosting space.

As to the rest of your post, I am very sorry, but I don’t follow what you mean. I can see that the config file is set to maintenance mode. I have taken a backup of my site - both the file tree and my NextCloud database.

Can you elaborate to help me understand what you are suggesting please?

Thank you

php occ upgrade
php occ maintenance:mode --off

Execute the commands via ssh. Probably in your nextcloud folder where a file with the name occ exist.

Edit: -off => --off

Thanks Daniel,

When I try “php occ upgrade”, I get this:-

"$ php occ upgrade
The current PHP memory limit is below the recommended value of 512MB.
Nextcloud is in maintenance mode - no apps have been loaded

Nextcloud is in maintenance mode
Maybe an upgrade is already in process. Please check the logfile (data/nextcloud.log). If you want to re-run the upgrade procedure, remove the “maintenance mode” from config.php and call this script again."

When I try “php occ maintenance:mode --off”

I get what looks like success. (Just to clarify, you have to specify double minus signs before the “off” at the end of the reset command, above).

So I am up and running again, still at 17.0.0… Although now I’m not sure about this particular update - I would prefer not to break everything again.

Thank you very much for your prompt and kind response - it was very helpful!

Consider raising the memory limit in php.ini.

Thank you… I’ve had some trouble attempting this in the past (increasing PHP Memory size) mainly due to the fact that this is a virtual server on a shared (ISP) hosting infrastructure - they’re not mad keen on individual clients tweaking settings. But I’ve asked. Can’t hurt to ask…