Unable to access directories starting with a hash sign

ℹ️ Support
1

I recently updated my Nextcloud installation from 10.0 to 10.0.2. At first everything seemed to work fine but then I noticed that one directory in my netxcloud account wouldn’t sync anymore. It’s a directory which is called “#heiseshow__Audio_” so what sets it apart from the rest is that it starts with a hash sign while all other directories just contain alphanumeric characters. The directory has been syncing fine for a long time before the update with the Nextcloud Android app and also via direct webdav access.

After looking through the log files, I couldn’t find anything relevant in the nextcloud.log. The only messages I found were in the Apache error log:

[Fri Dec 16 15:18:27.880156 2016] [proxy_fcgi:error] [pid 28538:tid 139631391663872] [client 127.0.0.1:51036] Invalid status line from script '%23heiseshow__Audio_': 0
[Fri Dec 16 15:27:29.464593 2016] [proxy_fcgi:error] [pid 28539:tid 139631290951424] [client 127.0.0.1:51412] Invalid status line from script '%23heiseshow__Audio_': 0

In case that isn’t obvious: I’m using Apache with php running via php-fpm and proxy_fcgi. This is a Debian stable installation so Apache is at version 2.4.10 and php at 5.6.x.

I can’t make sense of the error message apache is giving me. Could it be that the way the characters are encoded were changed between the two versions or something like that? I might add that it is also not possible create a new directory containing a hash sign, the same goes for other non-ascii characters that would be encoded like “ü”.

2

It works on NC 11. Did you set the default encoding of php to utf-8?

3

I’ve set

default_charset = "UTF-8"

internal, input and output encoding are not set and their comment in php.ini states that if they are not set, the default charset will be used.

I am still hesitant to upgrade to NC 11 since every OC or NC release up to now introduced major functionality breaking bugs.

4

I haven’t seen any major issues during the latest upgrades (OC 8.2 and later). But that is with the apache-php-module. In the past there have been some reports with fcgi-proxy that were a bit problematic but for me it was not clear if that is due to fcgi or due to “special” configurations of administration tools. So if you want to run several php instances with different permissions, I would take a look at nginx where we have working example configurations.

The snappy-image uses php-fpm as well, perhaps you can get some inspiration from their default configuration: https://github.com/nextcloud/nextcloud-snap/tree/master/src/php/config

5

Thanks, that set me on the right track. I previously used a ProxyPassMatch directive to connect to php-fpm:

ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:$port/var/www/owncloud/$1

The snap code uses a FilesMatch block and defines a handler with SetHandler instead to connect to php-fpm. Apparrently that’s now the preferred way to do it:

<FilesMatch \.php$>
         SetHandler "proxy:fcgi://127.0.0.1:$port"
</FilesMatch>

With that, access to the directory works again. I still wonder what has changed between 10.0 and 10.0.2 that led to the appearance of this issue but the most important thing is that everything works again.

2 Likes
6

Hello,

i have the same problem when i’m using:
ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://localhost:9003/var/www/owncloud/$1
I’m getting errors like:

[proxy_fcgi:error] [pid 8704] [client 93.209.104.xx:38672] Invalid status line from script ‘…’: 0

But disabling the ProxyPassMatch and creating a

<FilesMatch \.php$>
         SetHandler "proxy:fcgi://localhost:9003"
</FilesMatch>

does not fix the error for me… after that i’m getting the php source in browser…nothing is interpreted

I’m running a Nextcloud 11.0.7 beta on a:
Apache/2.4.7 (Ubuntu)
PHP 7.1.13-1+ubuntu14.04.1+deb.sury.org+1

mod mod_proxy_fcgi.so is loaded…

I’m pretty sure it’s something with my configuration…does anyone has an idea on whats going wrong?

Thank you!

1 Like
7

the workaround seem to depend on apache version. It only works on version > 2.4.25

8

It took me a week to finally get to this solution. With a different problem.

Thank You.