Using docker image, apps installed from App Management panel, have no effect if one is already present in image.

Expected behaviour

In ownCloud ran from docker image, apps installed from App Management panel, should be active/take precedence.

Actual behaviour

Apps are not active/do not take precedence.

Server configuration

Operating system: Dockerized image

ownCloud version: 10.15.0.2

Updated from an older ownCloud or fresh install: Update

Where did you install ownCloud from: Official docker image owncloud/server:10.15

Problem description

I’m running dockerized owncloud server, using openidconnect app for authentication. Since I have upgraded to docker image version 10.15 (i don’t exactly recall when, and which sub version, but currently I’m on 10.15.0.2) I have encountered problem with logging in of new users. I opened an issue on owncloud/openidconnect #326, and it came out it is a bug in app.

Since i have installed opeindconnet app with App Management panel, my plan was to test the possible fix, by modifying app’s php code in my owcloud/apps directory (I’m talking about owncloud directory, which is mounted in docker image, under /mnt/data). But to no avail the changes did not make any affect.

After some digging, into docker image content, I found out that openidconnect app already exists inside container, under path /var/www/owncloud/apps and those installed by App Management panel, reside under /var/www/owncloud/custom (as a link to /mnt/data/apps).

With some further digging, I found out that php paths are defined in config files as:

'apps_paths' => [
  0 => [
    "path" => OC::$SERVERROOT . "/apps",
    "url" => "/apps",
    "writable" => false
  ],
  1 => [
    "path" => OC::$SERVERROOT . "/custom",
    "url" => "/custom",
    "writable" => true
  ]
],

Given configuration is generated on each start of docker container from template: /etc/template/config.php (which is part of docker image).

The order of the paths, as defined in config file, prevents usage of apps installed from App Management panel, if corresponding app is already installed inside docker image.

My questions are as follows:

Is this intended behavior of docker image? This approach prevents us from installing updated version of the app, since app installed from App Management panel (possibly with some bug fixes), has no effect, since already existing installation in docker image, always take precedence.
Is there a way, to change order of apps_path since, adding modified config into owncloud/config directory makes no affect. (or at least I am unsuccessful in achieving to apply the changes)

Note:

Since I’m running production server, I had to apply necessary fix. To achieve that, I have copied entire content of /var/www/owncloud/apps directory, to my host machine, made changes in exported files, and mount them as volume in docker image overshadowing original /var/www/owncloud/apps directory.

While this solution works, it is not permanent solution since work will be have to be redone, once docker image is upgraded, and question of php path order still exists, since no updates from App Management panel, take effect.

the app loading logic will always grab the app with the highest app version. so you have to make the changes to the app with the highest version - if you have multiple versions installed.

in addition: it can be quite tricky to tell apache to reload the php code which lives in side the docker image .... no using the owncloud docker images - so I cannot really tell ....

It is not about choosing the app among multiple versions, it's about the fact, where apps are searched (at least I got to such conclusion).

It first searches for apps preinstalled inside image (directory /var/www/owncloud/apps), if it finds the app there, it does not check for apps installed by App Management panel, (which in turn reside in directory /var/www/owncloud/custom).

In short, if the app comes preinstalled with image, it ignores any new version installed by App Management panel. App preinstalled in container does not upgrade by itself, until entire docker image is upgraded.

Such behavior prevents, to install and use upgraded versions of any app.

Best I could understand it, this is the consequence of the order of app_paths array entries in config file:

'apps_paths' => [
  0 => [
    "path" => OC::$SERVERROOT . "/apps",
    "url" => "/apps",
    "writable" => false
  ],
  1 => [
    "path" => OC::$SERVERROOT . "/custom",
    "url" => "/custom",
    "writable" => true
  ]
],

In turn, this part of config file can not be changed, since it is generated from content of docker image, each time image is started (or at least I am unable to do it).

Of course, I am not 100% sure, that I got it right, thus I am asking the question, if this is intended behavior, and/or am I doing something wrong, when I want to change particular part of config file.

To summarize, it is not the problem of the app, but the container and it's configuration. I am only referring to my problem, because through resolving it, I came upon this one.

Thank you again, for your comment.

This function holds the logic to search for the app with the highest version in all app paths -

core/lib/private/App/AppManager.php

Line 727 in 6d5199a

protected function findAppInDirectories($appId) {

Can you please post the versions of the two apps please? - Look it up in the appinfo/info.xml - THX

I have checked app versions.

Both, the one which came in docker image, and one installed from App Management panel, are of the same version 2.3.0. That probably explains why the preinstalled one, takes precedence.

So. Works as designed. 🙈