Server version requests an upgrade over and over again

Steps to reproduce

Have no ideas how to reproduce it

Expected behaviour

Stop requesting an upgrade yourself and switch to maintenance mode.

Actual behaviour

Sometimes OwnCloud goes into maintenance mode. In this case, the ooc needs to be updated Applying the parameters below
‘upgrade.automatic-app-update’ => ‘false’,
‘upgrade.disable-web’ => ‘false’,
in config.php file did not give any results.
The upgrade request continues to appear.

Server configuration

Operating system: Debian 10
Web server: Apache/2.4.38
Database: 10.3.27-MariaDB
PHP version: PHP 7.3.19
ownCloud version:
Updated from an older ownCloud or fresh install: - fresh install with data restore.
Where did you install ownCloud from:
Signing status (ownCloud 9.0 and above):: Enterprise

Login as admin user into your ownCloud and access 
paste the results into and puth the link here.

No errors have been found.

List of activated apps:

  - activity: 2.6.0
  - comments: 0.3.0
  - configreport: 0.2.0
  - dav: 0.6.0
  - drawio: 0.0.9
  - external: 1.4.0
  - federatedfilesharing: 0.5.0
  - federation: 0.1.0
  - files: 1.5.2
  - files_external: 0.7.1
  - files_mediaviewer: 1.0.4
  - files_pdfviewer: 0.11.2
  - files_sharing: 0.13.0
  - files_texteditor: 2.3.0
  - files_trashbin: 0.9.1
  - files_versions: 1.3.0
  - firstrunwizard: 1.2.0
  - impersonate: 0.5.0
  - market: 0.6.0
  - notifications: 0.5.2
  - onlyoffice: 6.2.1
  - provisioning_api: 0.5.0
  - systemtags: 0.3.0
  - templateeditor: 0.4.0
  - user_external: 0.6.0
  - user_ldap: 0.15.2
  - admin_audit
  - announcementcenter
  - customgroups
  - encryption
  - enterprise_key
  - files_antivirus
  - files_classifier
  - files_external_dropbox
  - files_external_ftp
  - files_ldap_home
  - firewall
  - guests
  - oauth2
  - password_policy
  - ransomware_protection
  - sharepoint
  - systemtags_management
  - theme-enterprise
  - twofactor_totp
  - updatenotification
  - user_shibboleth
  - windows_network_drive
  - wopi
  - workflow

Are you using encryption: no

Are you using an external user-backend, if yes which one: LDAP

LDAP configuration (delete this part if not used)

| hasMemberOfFilterSupport      | 1 
| hasPagedResultSupport          |  
| homeFolderNamingRule          |  
| lastJpegPhotoLookup           |    
| ldapAgentName                 | uid=myuid,cn=mycn1,cn=mycn2,dc=mydc 
| ldapAgentPassword             | ***    
| ldapAttributesForGroupSearch  |  
| ldapAttributesForUserSearch   |    
| ldapBackupHost                |  
| ldapBackupPort                |  
| ldapBase                      | dc=mydc
| ldapBaseGroups                | cn=mycn1,cn=mycn2,dc=mydc   
| ldapBaseUsers                 | cn=mycn1,cn=mycn2,dc=mydc   
| ldapCacheTTL                  | 10   
| ldapConfigurationActive       | 1  
| ldapDynamicGroupMemberURL     |  
| ldapEmailAttribute            | mail     
| ldapExperiencedAdmin          | 1   
| ldapExpertUUIDGroupAttr       |     
| ldapExpertUUIDUserAttr        | myUUIDUserAttr  
| ldapExpertUsernameAttr        |   
| ldapGroupDisplayName          | cn 
| ldapGroupFilter               | (objectclass=myobjectclass)   
| ldapGroupFilterGroups         |  
| ldapGroupFilterMode           | 1 
| ldapGroupFilterObjectclass    |  
| ldapGroupMemberAssocAttr      | member  
| ldapHost                      |
| ldapIgnoreNamingRules         |  
| ldapLoginFilter               | (uid=%uid)  
| ldapLoginFilterAttributes     | 
| ldapLoginFilterEmail          |   
| ldapLoginFilterMode           | 1  
| ldapLoginFilterUsername       |
| ldapNestedGroups              |    
| ldapNetworkTimeout            | 2  
| ldapOverrideMainServer        | 0 
| ldapPagingSize                | 1000  
| ldapPort                      | myport
| ldapQuotaAttribute            | 
| ldapQuotaDefault              |   
| ldapTLS                       | 0    
| ldapUserDisplayName           | displayName   
| ldapUserDisplayName2          |   
| ldapUserFilter                | (objectclass=myobjectclass)
| ldapUserFilterGroups          | 
| ldapUserFilterMode            | 1  
| ldapUserFilterObjectclass     |   
| ldapUserName                  | someusername                          |
| ldapUuidGroupAttribute        | auto 
| ldapUuidUserAttribute         | auto 
| turnOffCertCheck              | 0 
| useMemberOfToDetectMembership | 1   

Client configuration

Browser: any

Operating system: any


Here is the console output during the upgrade:

ownCloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
 Set log level to debug
 Turned on maintenance mode
 Repair step: Upgrade app code from the marketplace
 Repair step: Repair MySQL database engine
 Repair step: Repair MySQL collation
 Repair info: All tables already have the correct collation -> nothing to do
 Repair step: Repair SQLite autoincrement
 Repair step: Repair orphaned reshare
 Repair step: Repair duplicate entries in oc_lucene_status
 Repair info: removing duplicate entries from lucene_status
 Updating database schema
 Updated database
 Updating <activity> ...
 Updated <activity> to 2.6.0
 Repair step: Repair mime types
 Repair step: Detect file cache entries with path that does not match parent-child relationships
 Repair step: Generate ETags for file where no ETag is present.
 Repair info: ETags have been fixed for 0 files/folders.
 Repair step: Clean tags and favorites
 Repair info: 0 tags of deleted users have been removed.
 Repair info: 0 tags for delete files have been removed.
 Repair info: 0 tag entries for deleted tags have been removed.
 Repair info: 3 tags with no entries have been removed.
 Repair step: Drop old database tables
 Drop old database tables 
 29/29 [============================] 100%2021-02-23T18:52:23+00:00 
 Repair step: Drop old background jobs
 Repair step: Remove getetag entries in properties table
 Repair info: Removed 0 unneeded "{DAV:}getetag" entries from properties table.
 Repair step: Repair invalid shares
 Repair step: Repair sub shares
 Repair step: Remove old share propagation app entries
 Repair step: Move user avatars outside the homes to the new location
 Repair info: No action required
 Repair step: Fix user avatars location
 Repair info: No action required
 Repair step: Remove shares of a users root folder
 Repair step: Repair unmerged shares
 Repair step: Disable extra themes
 Starting code integrity check...
 Finished code integrity check
 Update successful
 Turned off maintenance mode
 Reset log level

After that, it is available.
After a while, everything is repeated again.
It was not possible to identify patterns.

Has anyone come across?
Any ideas on how to fix unavailability when requesting an upgrade, or disable the upgrade altogether?

Hi danov,

in your upgrade log you can read

ownCloud or one of the apps require upgrade
Updated <activity> to 2.6.0

which means not ownCloud core itself had to be upgraded but an app, in this case activity.

So for every updated app you will see the update notification. This is required to update database tables and some other requirements before the new version can be used. (There are exceptions, but this is out of scope here).

I guess you had executed occ market:upgrade or upgraded the activity app manually, so this is intended behavior.

Conclusio: everytime you update an app run occ upgrade and you will be safe.

1 Like

Like @cortho already pointed out the update is requested because of an app.

I have seen this particular behavior if there are multiple app directories configured and the folder owncloud/apps is set to read only. Then it can happen that the marketplace puts a second updated version of your app into the writable directory and then you have the same app installed in two different versions which can lead to problems.

So perhaps you want to double check that.


Hi everyone.
Thanks for answers.
But I do not have a second folder with a different version of the app.
Also, the user has the permissions to write to the folder with the application.
What else could be the problem?

Paste at least your config.php and the relevant sections out of your owncloud.log then we might find the problem.

1 Like

Trying to upload files but get error:
New Users cannot upload attachments.

This is my config.php file

I don’t even know how to show you the logs.
In 10 minutes (it was not possible to more accurately determine the time when the upgrade was requested) it has 130,000 lines …
It is not possible to find an error or an upgrade request in the log.

Ty, config.php might be sufficient.
Have a look at the section app paths -> there you have got /path/to/folder/apps (not writable) and /path/to/folder/apps-external (writable) which leads us to @eneubauer’s comment

Then it can happen that the marketplace puts a second updated version of your app into the writable directory and then you have the same app installed in two different versions which can lead to problems.

As a quick solution you could delete every app folder in the apps directory which already has got another (newer) version in the apps-external directory (activity and maybe more).

Let us know if this worked for you.

@eneubauer Isn’t this something which should be fixed in core?


I agree with you, due to reasons I don’t understand, the developers have rejected my requests at fixing this.

(I guess that they don’t want to turn around and have the market place write in the apps folder, by deleting an app that is now installed in another directory. Why they can’t fix the weird upgrade behavior I still don’t understand)

We agreed now, that with the new occ app:list command all installed apps are shown with their install path. So you can at least see that you have apps installed multiple times and you can see which version is installed where.


I can only especulate about the reasons…

I think it’s because the “apps” directory is part of core, and you’re expected to remove it and replace it each new ownCloud version (as the documentation says, you’re expected to remove everything except the “config” and “data” folders).
3rd party apps not bundled by ownCloud should be installed in the “apps-external” directory. I guess the expectation is that this directory is out of the ownCloud directory, but since we can’t provide a good default, the easiest option is to create it inside the ownCloud directory.

As said, before the upgrade, you’re expected to remove the old ownCloud installation except for the “config” and “data” directories. The “apps-external” directory shouldn’t be removed neither, assuming it’s still inside the ownCloud directory.
After the upgrade, you’ll have the new ownCloud version with the updated bundled apps, but you’ll keep the 3rd party apps the same as before. I guess this is the reason.

For docker setups, I think this secondary apps location is expected to be in an external volume to make the upgrade easier just by replacing the docker image.


I can follow your explanations (and I know that is your personal insight, I’m pretty fine with that), I might even understand the developers’ points of views, but from an end user perspective this is a perfect chaos.

as the documentation says, you’re expected to remove everything except the “config” and “data” folders

No, it doesn’t:

3rd party apps not bundled by ownCloud should be installed in the “apps-external” directory

This is where we come to the “slick” versus the package. The latter one hat twofactor_totp in the bundle until 10.5, now it’s not there any longer. So there is no clear answer to the question, which apps are bundled with ownCloud.

Then there is the marketplace app issue. When having read-only and write apps folders, the app will store the upgraded app in apps-external (or whatever is the name). This is fine.

But then, ownCloud gets into trouble with itself, not knowing which app is the “current” one, ignoring the other.

To me it seems that this issue could be easily solved, if there is some good will. Since ownCloud is browsing the apps directories anyway there are two ways to escape the upgrade endless-loop, if an app exists (with different versions) in both directories.

  • only use the one from the writable directory
  • only use the most recent version

This is a decision which has to be made and then clearly communicated.

I might understand when the developers do not have got any time, because they are all occupied with OCIS, but then I’d expect a clear word as well: “Wontfix, we don’t care about the ‘old’ ownCloud any longer”.

From a user’s point of view I cannot understand why developers reject this request, the situation can lead to insane situations, especially when the documention does not consider this issue.


As far as I know, it should always be using the latest version available, so once the app is upgraded it shouldn’t request the same upgrade. I don’t remember if there was a problem that has been fixed already…

I don’t see any clear steps to reproduce, and the cause isn’t clear. This doesn’t seem an easy fix that can be sneaked in.

Do you have a link to the github ticket? I can try to shake things a bit.


It has been 8 days since the configuration change.
There was not a single upgrade request that blocked work with the system.
What is done:
Removed the Activity directory from the read-only folder /apps.
This solved my problem.
Thanks everyone for the detailed answers!


@jvillafanez thank you for your efforts, I did not file a ticket, I had seen this behavior on some instances though.

My aim was to share my opinion, so developers might know that the community is “not amused”. And - proven with this thread - users stumble upon this phenomenon and do not know how to solve it.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.