Server: Missing icons in Files app after 12.0.1 upgrade

[ladrua]

Steps to reproduce

1. Upgrade to 12.0.1 manual from source.
2. run occ upgrade
3. Go to Files app.

Expected behaviour

Normal files view.

Actual behaviour

Files view is missing all icons, seems like some css is not acting as it should either. No errors found in log or in browser.

Server configuration

Operating system:
ubuntu 14.04.5 docker image
Web server:
Apache 2.4
Database:
MySQL 5.7.19
PHP version:
PHP 7.0
Nextcloud version: (see Nextcloud admin page)
12.0.1.5
Updated from an older Nextcloud/ownCloud or fresh install:
12.0.0.39
Where did you install Nextcloud from:
Download stable sources from nextcloud.com

[pixelipo]

Sounds like permissions issue to me. Nextcloud needs to be able to generate CSS file out of existing (S)CSS ones.

[ladrua]

Yeah, thats what I thought too, but ran chown www-data -R nextcloud/ just to be sure, still problem. And its only the Files app, the others are ok.

[pachulo]

Hey @ladrua ! Does this looks like the bug you are seeing?

[ladrua]

@pachulo yes, exactly.

[pachulo]

Well, we are experiencing this behaviour also in the nextcloud snap, as described here https://github.com/nextcloud/nextcloud-snap/pull/334#issuecomment-320787077

We are seeing these errors in the Chrome dev tools console:

With the error pointing to this piece of Javascript:

My Javascript/CSS foo is weak, so I cannot really tell why it is adding that "cs" to the ".nav-icon-favorites" style:

For example:
http://localhost/cs/apps/files/img/share.svg?v=1 -> 404
http://localhost/apps/files/img/share.svg?v=1 -> 200

Besides that, Firefox dev tools show this error when trying to inspect a missing icon:

It basically says that it could not load it.

For the record: I've also tried spinning a nextcloud Docker container with 12.0.1 (using this https://github.com/nextcloud/docker) and the icons are shown OK.

[ladrua]

I am not getting those error messages, actually no error messages at all.

[sroracle]

Having a similar issue upon upgrading to 12.0.1.
. Developer console has this to say:

Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src 'nonce-Q0NRZGx3bzUzM3YwU0FqSDBOU0ZPRXRVdTVSQkt3cmdHR05ZK1JPeTlSND06UDAxUm9HVUtxaFdrUEg2L2w3SE1kVEU5ek5rTFhscVJXZ1FpZ1hubHAxQT0=' 'unsafe-eval'”). Source: onsubmit attribute on DIV element.
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src 'nonce-Q0NRZGx3bzUzM3YwU0FqSDBOU0ZPRXRVdTVSQkt3cmdHR05ZK1JPeTlSND06UDAxUm9HVUtxaFdrUEg2L2w3SE1kVEU5ek5rTFhscVJXZ1FpZ1hubHAxQT0=' 'unsafe-eval'”). Source: onchange attribute on DIV element.
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src 'nonce-Q0NRZGx3bzUzM3YwU0FqSDBOU0ZPRXRVdTVSQkt3cmdHR05ZK1JPeTlSND06UDAxUm9HVUtxaFdrUEg2L2w3SE1kVEU5ek5rTFhscVJXZ1FpZ1hubHAxQT0=' 'unsafe-eval'”). Source: onfocusin attribute on DIV element.

nextcloud.log:

{"reqId":"nFRG5VopzGXvpjzzevRL","level":3,"time":"2017-08-10T08:04:56+00:00","remoteAddr":"76.29.2.249","user":"mcrees","app":"lib","method":"GET","url":"\/apps\/files\/","message
":"ResourceLocator can not find a web root (root: \/usr\/share\/webapps\/nextcloud\/apps\/files, file: css\/files\/97738d638fe5012b793d0a1648c632d0-merged.css, webRoot: , throw: true)","userAgent":"Mozilla\/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/58.0.3029.110 Safari\/537.36","version":"12.0.1.5"}

[zenny]

+1 this bug haunted me after the upgrade to 12.0.1 in alpine linux. Is there a way to downgrade?

[kyrofa]

@sroracle that sounds an awful lot like https://github.com/nextcloud/server/issues/5057 ... are you sure you're not on v12.0.0?

[tatwaffe]

Running into same issue after upgrading to 12.0.1

NC LOG:

{"reqId":"DEJNW6Og0FAltsTeIEfc","level":3,"time":"2017-08-11T10:38:38+02:00","remoteAddr":"83.164.193.18","user":"admin","app":"lib","method":"GET","url":"\/apps\/files\/","message":"ResourceLocator can not find a web root (root: \/srv\/web\/nextcloud\/apps\/files, file: css\/files\/1130ef96bf4e8bb336970e2ff913b21c-merged.css, webRoot: , throw: true)","userAgent":"Mozilla\/5.0 (X11; Fedora; Linux x86_64; rv:54.0) Gecko\/20100101 Firefox\/54.0","version":"12.0.1.5"}
{"reqId":"DEJNW6Og0FAltsTeIEfc","level":3,"time":"2017-08-11T10:38:38+02:00","remoteAddr":"83.164.193.18","user":"admin","app":"lib","method":"GET","url":"\/apps\/files\/","message":"ResourceLocator can not find a web root (root: \/srv\/web\/nextcloud\/apps\/files_sharing, file: css\/files_sharing\/1130ef96bf4e8bb336970e2ff913b21c-mergedAdditionalStyles.css, webRoot: , throw: true)","userAgent":"Mozilla\/5.0 (X11; Fedora; Linux x86_64; rv:54.0) Gecko\/20100101 Firefox\/54.0","version":"12.0.1.5"}
{"reqId":"DEJNW6Og0FAltsTeIEfc","level":3,"time":"2017-08-11T10:38:38+02:00","remoteAddr":"83.164.193.18","user":"admin","app":"lib","method":"GET","url":"\/apps\/files\/","message":"ResourceLocator can not find a web root (root: \/srv\/web\/nextcloud\/apps\/files_texteditor, file: css\/files_texteditor\/1130ef96bf4e8bb336970e2ff913b21c-merged.css, webRoot: , throw: true)","userAgent":"Mozilla\/5.0 (X11; Fedora; Linux x86_64; rv:54.0) Gecko\/20100101 Firefox\/54.0","version":"12.0.1.5"}

I use symlinks as follows:

apps -> /srv/gluster/vol0/nextcloud/apps/
apps_c -> /srv/gluster/vol0/nextcloud/apps_c/
config -> /srv/gluster/vol0/nextcloud/config
data -> /srv/gluster/vol0/nextcloud/data

Documentroot is
"/srv/web/nextcloud"

Workaround:
Set manually $tmpRoot to DocumentRoot "/srv/web/nextcloud"

/lib/private/Template/CSSResourceLocator.php 
do {
+                                      $tmpRoot='/srv/web/nextcloud';
                                        if (isset($this->mapping[$tmpRoot])) {
                                                $webRoot = $this->mapping[$t

[zenny]

@tatwaffe , Thanks for the pointer, but in my case, it was pointing to a different folder, thus assigning $tmpRoot='/usr/share/webapps/nextcloud' seems of no help:

"message":"ResourceLocator can not find a web root (root: \/usr\/share\/webapps\/nextcloud\/apps\/files_texteditor, file: index.php\/css\/files_texteditor\/761d09b04274346884d55b9f24176730-merged.css, webRoot: , throw: true)",

The symlinks are all pointing to where they should except I couldn't see an apps_c pointer, fyi.

[zenny]

Mine seems like the _long outstanding bug_ as discussed here: https://github.com/nextcloud/server/issues/5081 and https://github.com/nextcloud/server/issues/5057. More specifically https://github.com/nextcloud/server/pull/5252 and https://github.com/nextcloud/server/issues/5289#issuecomment-307553972 which does not seem to address the issue. :-(

[rnalrd]

Same problem here after upgrade 12.0.0->12.0.1

Log shows:

{"reqId":"JsFxKMADXgdgMYC0IUEv","level":3,"time":"2017-08-11T19:34:31+00:00","remoteAddr":"192.168.1.1","user":"rnalrd","app":"lib","method":"GET","url":"\/index.php\/apps\/files\/?dir=\/","message":"ResourceLocator can not find a web root (root: \/usr\/share\/webapps\/nextcloud\/apps\/files, file: index.php\/css\/files\/792abc1ff25ef03a8bac471ecd9f6842-merged.css, webRoot: , throw: true)","userAgent":"Mozilla\/5.0 (X11; Linux x86_64) AppleWebKit\/537.36 (KHTML, like Gecko) Ubuntu Chromium\/59.0.3071.109 Chrome\/59.0.3071.109 Safari\/537.36","version":"12.0.1.5"}
{"reqId":"JsFxKMADXgdgMYC0IUEv","level":3,"time":"2017-08-11T19:34:31+00:00","remoteAddr":"192.168.1.1","user":"rnalrd","app":"lib","method":"GET","url":"\/index.php\/apps\/files\/?dir=\/","message":"ResourceLocator can not find a web root (root: \/usr\/share\/webapps\/nextcloud\/apps\/files_sharing, file: index.php\/css\/files_sharing\/792abc1ff25ef03a8bac471ecd9f6842-mergedAdditionalStyles.css, webRoot: , throw: true)","userAgent":"Mozilla\/5.0 (X11; Linux x86_64) AppleWebKit\/537.36 (KHTML, like Gecko) Ubuntu Chromium\/59.0.3071.109 Chrome\/59.0.3071.109 Safari\/537.36","version":"12.0.1.5"}
{"reqId":"JsFxKMADXgdgMYC0IUEv","level":3,"time":"2017-08-11T19:34:31+00:00","remoteAddr":"192.168.1.1","user":"rnalrd","app":"lib","method":"GET","url":"\/index.php\/apps\/files\/?dir=\/","message":"ResourceLocator can not find a web root (root: \/usr\/share\/webapps\/nextcloud\/apps\/files_texteditor, file: index.php\/css\/files_texteditor\/792abc1ff25ef03a8bac471ecd9f6842-merged.css, webRoot: , throw: true)","userAgent":"Mozilla\/5.0 (X11; Linux x86_64) AppleWebKit\/537.36 (KHTML, like Gecko) Ubuntu Chromium\/59.0.3071.109 Chrome\/59.0.3071.109 Safari\/537.36","version":"12.0.1.5"}

_apps_ and _config_ are symlinked outside the installation directory.

[sroracle]

@kyrofa logging in as administrator confirms that I'm running 12.0.1 and all integrity checks have passed.

After reading this comment I moved the apps directory from /var/lib/nextcloud/apps to /usr/share/webapps/nextcloud/apps (essentially in the document root), and the issue appears to be resolved. For any fellow Alpine users out there, this is a workaround if you are able and willing to move the apps directory, but this will break future package updates (you'll have to manually merge changes) unless we can get whoever maintains the Alpine package to change this.

[zenny]

@sroracle, yep moving the entire /var/lib/nextcloud/apps to /usr/share/webapps/nextcloud/apps solved this issue. Maybe others have different mileages! Thanks!

[gramakri]

We hit this issue on the Cloudron NextCloud package as well (https://git.cloudron.io/cloudron/nextcloud-app/issues/22). We also symlink the _apps_ outside the installation directory. Unfortunately, moving apps inside the installation dir is a no-go because on the Cloudron the installation is read-only. Is there any other workaround?

[rnalrd]

@soracle Alpine edge changed location for the built-in apps back to the
installation directory.
Can you check if it works in edge? If yes I can backport the change for
3.6-stable too.
Thanks

Il 11 ago 2017 10:45 PM, "sroracle" [e-mail] ha scritto:

@kyrofa https://github.com/kyrofa logging in as administrator confirms
that I'm running 12.0.1 and all integrity checks have passed.

After reading this comment
https://github.com/nextcloud/server/issues/5289#issuecomment-307553972 I
moved the apps directory from /var/lib/nextcloud/apps to
/usr/share/webapps/nextcloud/apps (essentially in the document root), and
the issue appears to be resolved. For any fellow Alpine users out there,
this is a workaround if you are able and willing to move the apps
directory, but this will break future package updates (you'll have to
manually merge changes) unless we can get whoever maintains the Alpine
package to change this.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/server/issues/6028#issuecomment-321914534,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACqrPEBldxpN-w-btKGg49I6z78eg9Xpks5sXL1ZgaJpZM4Owl-Y
.

[sroracle]

@rnalrd I added edge/community to /etc/apk/repositories and ran apk update then reinstalled nextcloud but there was no change. Can you link to the commit? I can't find it.

[rnalrd]

@sroracle there you go:

https://git.alpinelinux.org/cgit/aports/commit/?id=56340e0c374f9f287da09df6dbf52894d2ea4861

[sroracle]

@rnalrd I could not get the setup proposed in that commit to work. It seems either nginx or nextcloud really dislikes having apps in two separate paths. I managed to get e.g. apps1 (apk) and apps2 (app store) in /usr/share/webapps/nextcloud to work, though.

[nebulade]

I can also confirm that in the Cloudron case, the issue is related to the symlinked apps/ folder. Could this have to do with some relative includes in one of the core apps, which expect the apps folder to be absolute in the main nextcloud directory?

[ghost]

Same problem on my Synology DS215j. The problem only appears when using PHP 7.0. If I switch to PHP 5.6, i can see the icons again.

[pachulo]

I've just tried to build a snap with nextcloud 12.0.2 and PHP 7.1.8 and I'm getting the same error, but now with differents paths (doc instead of cs):

Don't really know what's going on.

[nebulade]

After bisecting, the issue is introduced with f0753cb56d3b348aa16ac4481d32e9531a9958fb

So given http://php.net/manual/en/function.realpath.php this explains how any symlink in between will break it.

[nebulade]

Reverting the change in question does work on top of 12.0.2 fine, at least I have not encountered any side effects. Does anyone know what the main intention for f0753cb56d3b348aa16ac4481d32e9531a9958fb was? Thanks.

[pachulo]

hey @nebulade, good find! That commit was a solution for https://github.com/nextcloud/server/issues/5057 using the workaround proposed by @sileht : https://github.com/nextcloud/server/issues/5057#issuecomment-306191311
Before that, it was even worse for the nextcloud snap https://github.com/nextcloud/nextcloud-snap/issues/280

[juliushaertl]

As commented in https://github.com/nextcloud/server/issues/6271#issuecomment-325197723 which seems to be the same issue:

Can you try setting the htaccess.IgnoreFrontController config to true and check if that fixes your issue?

[nebulade]

@juliushaertl the IgnoreFrontController setting did not help in this case, in fact I was not able to bring it into a state where the url rewrite works correctly at all, despite having a working mod_rewrite.

[tflidd]

We are on a similar issue with the pretty URLs (#6271), it seems to help to make minor changes to theming (e.g. change background color via admin-page). This way, all the theming stuff is cleared from cache.

[MorrisJobke]

Fix seems to be in #6332. Could you please have a look and test this?

[ghost]

Changed the files and my icons reappeared.

[pachulo]

I've tried to change the files with the ones in the https://github.com/nextcloud/server/pull/6332 PR but it didn't solve the problem for the snap. Still getting an cs added in the path:

[juliushaertl]

@pachulo Can you try to change the color in the theming app and see if the icons will appear then? Because that will trigger rebuilding the CSS files, which will be done automatically in the future with #6352

[pachulo]

Hey @juliushaertl ! I did try to change the color, but the missing icons are still there...

[kyrofa]

Yeah, no go on the snap. Where the files app (apps/files/css/files.scss) shows e.g.

.nav-icon-files {
        background-image: url('../img/folder.svg?v=1');
}

the compiled CSS shows:

.nav-icon-files{
    background-image:url('../../../docs/apps/files/css/../img/folder.svg?v=1')
}

That's not even close to valid. How did "docs" get in there?

[kyrofa]

The config is perhaps a little unusual in two ways, both by using symlinks and by using multiple app directories. Here's the config:

{
    "system": {
        "apps_paths": [
            {
                "path": "\/snap\/nextcloud\/current\/htdocs\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/snap\/nextcloud\/current\/nextcloud\/extra-apps",
                "url": "\/extra-apps",
                "writable": true
            }
        ],
        "supportedDatabases": [
            "mysql"
        ],
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "\/tmp\/sockets\/redis.sock",
            "port": 0
        },
        "instanceid": "ocyncb2txywd",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "pandora.local"
        ],
        "datadirectory": "\/var\/snap\/nextcloud\/common\/nextcloud\/data",
        "overwrite.cli.url": "http:\/\/pandora.local",
        "dbtype": "mysql",
        "version": "12.0.2.0",
        "dbname": "nextcloud",
        "dbhost": "localhost:\/tmp\/sockets\/mysql.sock",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true
    }
}

[tux-rampage]

@kyrofa Could you provide the following information:

What ist the path of the document root?
Output of ls -l <path_to_docroot> and ls -l -d <path_to_docroot>. Replace <path_to_docroot> with the actual path to your document root.

[tux-rampage]

if lib is a symlink, this will be the issue:

OC::$SERVERROOT = str_replace("\\", '/', substr(__DIR__, 0, -4)); 

If lib is linked, this code results in a completely incorrect root directory. Apart form the substring() call, where dirname would be more readable, we should utilize env vars like DOCUMENT_ROOT or NC_SERVER_ROOT if set and fall back to the existing installation?

[kyrofa]

@tux-rampage sure thing!

The document root is /snap/nextcloud/2978/htdocs. This is not a symlink, however, in the config above, the first app path is /snap/nextcloud/current/htdocs/apps, where current is a symlink pointing to 2978. Note that 2978 is a revision number that changes over time, thus the use of the current symlink in the config.

Note that, although a different directory, the second app path, /var/snap/nextcloud/current/nextcloud/extra-apps, is also a symlink pointing to /var/snap/nextcloud/2978/nextcloud/extra-apps.

Here is the output of the commands you requested:

$ ls -l /snap/nextcloud/2978/htdocs/
total 75
drwxr-xr-x 31 root root   738 Sep 10 11:05 3rdparty
drwxr-xr-x 35 root root   931 Sep 10 11:04 apps
-rw-r--r--  1 root root  8868 Sep  9 18:00 AUTHORS
drwxr-xr-x  2 root root    97 Sep 10 11:06 config
-rw-r--r--  1 root root  4050 Sep  9 18:00 console.php
drwxr-xr-x 16 root root   373 Sep 10 11:05 core
-rw-r--r--  1 root root  5057 Sep  9 18:00 cron.php
-rw-r--r--  1 root root 41077 Sep  9 18:00 db_structure.xml
-rw-r--r--  1 root root   179 Sep  9 18:00 index.html
-rw-r--r--  1 root root  2804 Sep  9 18:00 index.php
drwxr-xr-x  3 root root    76 Sep 10 11:05 l10n
drwxr-xr-x  6 root root   134 Sep 10 11:05 lib
-rw-r--r--  1 root root   283 Sep  9 18:00 occ
drwxr-xr-x  2 root root    82 Sep 10 11:05 ocs
drwxr-xr-x  2 root root    32 Sep 10 11:05 ocs-provider
-rw-r--r--  1 root root  3152 Sep  9 18:00 public.php
-rw-r--r--  1 root root  5323 Sep  9 18:00 remote.php
drwxr-xr-x  4 root root    48 Sep 10 11:05 resources
-rw-r--r--  1 root root    26 Sep  9 18:00 robots.txt
drwxr-xr-x 14 root root   312 Sep 10 11:05 settings
-rw-r--r--  1 root root  2110 Sep  9 18:00 status.php
drwxr-xr-x  3 root root    44 Sep 10 11:05 themes
drwxr-xr-x  2 root root    52 Sep 10 11:05 updater
-rw-r--r--  1 root root   434 Sep  9 18:02 version.php

$ ls -l -d /snap/nextcloud/2978/htdocs/
drwxr-xr-x 14 root root 490 Sep 10 11:04 /snap/nextcloud/2978/htdocs/

Note that this is using the v12 daily tarball.

[pachulo]

Do you have any news on this @tux-rampage ?

[tux-rampage]

@pachulo not yet, sorry. It seems to many symliks is a bit too much for the resource locators. Especially when the docroot and apps is a symlink. But I had no time to investigate this further.

[kyrofa]

Then perhaps we should re-open this issue?

[nebulade]

From my previous comment https://github.com/nextcloud/server/issues/6028#issuecomment-324457558 is there anyone with deeper understanding on the commit https://github.com/nextcloud/server/commit/f0753cb56d3b348aa16ac4481d32e9531a9958fb and how to fix it for the symlink and snap case? Thanks a lot.

[kyrofa]

I'm happy to test any ideas, here. We still have thousands of people stuck on v11 because of this.

[tux-rampage]

Unfortunately this is not trivial, I had no time for further analyzing this issue, yet.

[kyrofa]

I don't actually know anything, but I'm poking about. Something seems funny here. The mapping is always '/snap/nextcloud/2978/htdocs' => '', so the webroot is always ''. Is that correct?

[kyrofa]

Ah, I'm making some headway here. Here is where the SCSS URL rewrites happen. Relevant snippet:

$path = implode('/', $path);
$webDir = substr($path, strlen($this->serverRoot)+1);

$path in this case is, say, /snap/nextcloud/current/htdocs/apps/files/css. However, $this->serverRoot is /snap/nextcloud/x1/htdocs (or 2978 per the example above, point is, the symlink versus the real path), which means the strlen isn't quite right, the substr doesn't do what we expect, and $webDir ends up with docs/apps/files/css where "docs" is the last bit of "htdocs". If the revision was 2978 instead of x1, we'd get cs/apps/files/css, like @pachulo has been seeing.

Pretty sure a sprinkling of realpath in the right spot here will solve it.

[kyrofa]

There we go, that fixes things. I'm not 100% sure it's fixed in the right place, but at least it fixes things.

[kyrofa]

Okay I'm more certain THAT is in the correct place.

[pipiche38]

This issue seems to still be in 12.0.4
Here is an extract of my config file and if the app is stored on the /var/lib/nextcloud/apps directory - and not on the /usr/share/nextcloud/apps - I got the issue
'apps_paths' =>
array (
0 =>
array (
'path' => '/usr/share/nextcloud/apps',
'url' => '/apps',
'writable' => false,
),
1 =>
array (
'path' => '/var/lib/nextcloud/apps',
'url' => '/apps-appstore',
'writable' => true,
),
),

[RussianNeuroMancer]

I have this issue on 12.0.4 too.

[tflidd]

Can you share a bit more information that the developers can reproduce this problem? Is this on new setups, only on updated, which webserver, ...

[RussianNeuroMancer]

Is this on new setups, only on updated

Updated from 12.0.3 (and previously from every NextCloud release, and before that migrated from OwnCloud).

which webserver

Apache 2.4.29-1 build with enabled http2 module by deb.sury.org, php-fpm 7.1.11 and PostgreSQL 9.6.6 from Ubuntu Server 17.10 repository. What else could help find root cause of this issue?

[RussianNeuroMancer]

Issue is gone after update to 12.0.5.

[ladrua]

Issue is fixed after update to 13.0.0