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 “ü”.
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 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:
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.