Have you also set the url in (should normally only be related to links created by php-cli->cronjobs): 'overwrite.cli.url' => 'https://example.org/nextcloud',
mod_rewrite and mod_env are installed. overwrite.cli.url was there the entire time. I spend several hours debugging and looking through related articles so I hope I can rule out the obvious…
How does your apache-settings look like? Did you put an AllowOverride all for the nextcloud directory in order to activate the .htaccess settings?
Other links to specific apps or folder work? You are on version 10.0.1? It happens on all browsers?
.htaccess is working (eg the X-Headers are set). Yes it happens in all browsers. Since the links are simply incorrect I fail to see how different browsers would behave differently.
I can report the same issue. Even without a proxy.
I just installed version 11.0 on a new VM. I originally set Apache2 up with a site configuration (virtual server) before setting up Nextcloud, then I changed my mind and altered that to a conf configuration (in the default virtual server) with an alias putting Nextcloud into /nextcloud instead of the root.
It has broken the image files in the drop down menus, but everything else (file upload/download/admin pages/files app/gallery app etc) seems to work. It looks like whatever generates the images isn’t respecting the path everything else does.
e.g. the webserver presents /settings/img/personal.svg to my browser (404 error)
If I edit to /nextcloud/settings/img/personal.svg then the picture comes up.
I just gave this a try and it didn’t change the behaviour I’m seeing. The documentation says that setting is for “using any kind of command line tools (cron or occ)”.
Apache2 conf: Alias /nextcloud "/var/www/nextcloud/"
<Directory "/var/www/nextcloud">
Options +FollowSymLinks
AllowOverride All
<IfModule mod_dav.c>
Dav off
</IfModule>
SetEnv HOME /var/www/nextcloud
SetEnv HTTP_HOME /var/www/nextcloud
Satisfy Any
</Directory>
I did some more digging. Looking at the source of the HTML, most paths have /nextcloud but some don’t.
I stopped Apache2, ran htcacheclean and restarted it. I cleared Chrome’s history/cache completely and tried again (and from a new browser on a different machine). Same result.
Given that the HTML being delivered to the browser contains incorrect paths to the images, then it doesn’t feel like a caching issue. It feels more like a bug?
Out of interest, I installed the two themes from here just in case there was a bug in the main theme but it didn’t fix the image paths (which must be defined elsewhere?):
Out of interest, I installed a new, fresh Nextcloud into /nextcloud2 (i.e., installed already not at the web root). It installed fine and the icons are all displaying. I had a look at config.php and .htaccess and couldn’t see anything very different.
I can (and will) proceed by deleting my planned installation and reinstalling, but I feel there is something out there to fix at some point.
Good that it works, however it is strange that it doesn’t work for the other setup. Open perhaps a bug report on github. Only thing I could still think of is that in the *_storage(s)-table the path to the data-directory is wrong. But I can’t imagine that this is related to the favicon.ico-error.
Hi, I have the same issue of several icons in Files App not being retrieved (404 from server, eg. /s/img/folder.svg?v=1), currently in NC12. Has there been some progress in this issue lately?
I fixed the problem with direct editing CSS definitions for the icons in Files App in the file apps/files/css/files.scss. The urls needed to be changed from …/img/[image].svg to …/…/apps/files/img/[image].svg.
etc. trying back and forth didn’t solve the problem. So using index.php-less URL seems to somehow break the default (non app) theming, making nextcloud looking for the related svg files in web root instread of /nextcloud.
