Installed apps show white screen unless symlinked from system apps directory

[zwets]

Steps to reproduce

1. Set up a working 19.0.0 installation with a non-writable (root-owned) document root, and a separate writable "installed apps" directory located outside the document root.

    # In config.php:
    'apps_paths' => [
      [ 'path' => '/var/www/html/example.com/apps',
        'url' => '/apps',
        'writable' => false ],
      [ 'path' => '/var/opt/lib/nextcloud/apps',
        'url' => '/userapps',
        'writable' => true ] ]
   

2. Logged in as admin, download and enable some featured apps. E.g. Tasks, Notes, and Deck.

3. Note that after installation their name appears when hovering in the blue menu bar, but their icon doesn't.

4. Click any of the newly installed apps in the menu bar. Instead of the app, a white screen appears. There are no errors in the log.

Workaround

1. Create a symlink in the "system apps" directory for each app installed in the "installed apps" directory:

    cd /var/www/html/example.com/apps
    sudo ln -sft "." /var/opt/lib/nextcloud/apps/*
   

2. Reload the page in NextCloud. The newly installed apps now show up with their icons in the menu bar, and work as they should.

Server configuration

• Ubuntu Server 18.04 (plain vanilla), with Apache 2.4.29, PostgreSQL 10, PHP 7.2.

• Nextcloud 19.0.0, updated from 18.0.4, installed from release tarball.

• NextCloud is installed at "/" on the server, i.e. is available on https://example.com/, through the required config.php settings:

      # In config.php (and applied: `occ maintenance:update:htaccess`):
      'overwritehost' => 'example.com',
      'overwriteprotocol' => 'https',
      'overwrite.cli.url' => 'https://example.com/',
      'htaccess.RewriteBase' => '/',
  

Client configuration

• Firefox 77.0.1 on Ubuntu 20.04.

Diagnostic Info

• The browser console shows that the initial request for an installed app page is directed at the /apps context and succeeds (e.g. for the Notes app):

  • https://example.com/apps/notes/ 200 OK, and yields an HTML body

• This page then requests resources in the /userapps context, and these receive a faulty 302 redirect:

  • https://example.com/userapps/notes/img/notes.svg?v=c4c1257e 302 Found, Location: https://example.com/apps/files/
  • https://example.com/userapps/notes/l10n/en_GB.js?v=c4c1257e-24 302 Found, Location: https://example.com/apps/files/
  • https://example.com/userapps/notes/js/notes.js?v=c4c1257e-24 302 Found, Location: https://example.com/apps/files/

• When the symlink workaround is present, the same requests are made, however they now point into the /apps/ contextroot and succeed:

  • https://example.com/apps/notes/l10n/en_GB.js?v=c4c1257e-24 200 OK
  • https://example.com/apps/notes/js/notes.js?v=c4c1257e-24 200 OK

All through this, there are no error messages in the log. There is just the ubiquitous warning ResourceLocator can not find a web root (root: /var/opt/lib/nextcloud/apps/notes), file: css/..., but this is present regardless of the workaround.

[kesselb]

https://docs.nextcloud.com/server/19/admin_manual/apps_management.html#using-custom-app-directories

What you describe as workaround is actually a required step. In your case https://nc.com/userapps/ must be a symlink (maybe a alias also works) to /var/opt/lib/nextcloud/apps. To serve static app assets for example.

We should probably make that more clear with the documentation. Mind to send a pull request? :)

[zwets]

PR nextcloud/documentation#2139 adds the missing documentation.

This issue could be closed, but it's still desirable if the symlinking weren't needed. It's an awkward extra step, and needs redoing after every upgrade (assuming "erase & unpack", which is the likely approach for deployments with a read-only docroot).

I experimented with setting an Alias in Apache. This looks like the better solution, as it's unaffected by reinstalls and upgrades, and makes the outside path explicit in the Apache config. However, I kept running into 403 Forbiddens even when I loosened the directives inside <Directory /path/to/userapps> or set them identical to those for the NC root.

It should be doable, but needs some digging and tinkering.