SCSSCacher tried to delete document root?

[Cybso]

After upgrading Nextcloud from 13.0.0 to 13.0.2 via occ it reported me the following error:

{
"version" : "13.0.2.1",
"level" : 3,
"reqId" : "FVhZt7vIPnbUeQxouvZr",
"user" : "username",
"remoteAddr" : "ipaddr",
"method" : "GET",
"url" : "/apps/files/",
"userAgent" : "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.189 Safari/537.36 Vivaldi/1.95.1077.60",
"time" : "2018-04-26T15:51:38+00:00",
"message" : "Exception: {"Exception":"OCP\\Files\\NotPermittedException","Message":"","Code":0,"Trace":"#0 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/Files\/SimpleFS\/SimpleFile.php(138): OC\\Files\\Node\\File->delete()\n#1 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/Template\/SCSSCacher.php(269): OC\\Files\\SimpleFS\\SimpleFile->delete()\n#2 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/Template\/SCSSCacher.php(180): OC\\Template\\SCSSCacher->resetCache()\n#3 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/Template\/SCSSCacher.php(123): OC\\Template\\SCSSCacher->variablesChanged()\n#4 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/Template\/CSSResourceLocator.php(109): OC\\Template\\SCSSCacher->process('\/srv\/www\/cloudd...', 'core\/css\/jquery...', 'core')\n#5 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/Template\/CSSResourceLocator.php(61): OC\\Template\\CSSResourceLocator->cacheAndAppendScssIfExist('\/srv\/www\/cloudd...', 'core\/css\/jquery...')\n#6 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/Template\/ResourceLocator.php(78): OC\\Template\\CSSResourceLocator->doFind('css\/jquery-ui-f...')\n#7 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/TemplateLayout.php(270): OC\\Template\\ResourceLocator->find(Array)\n#8 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/TemplateLayout.php(186): OC\\TemplateLayout::findStylesheetFiles(Array)\n#9 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/legacy\/template.php(207): OC\\TemplateLayout->__construct('user', 'files')\n#10 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/public\/AppFramework\/Http\/TemplateResponse.php(157): OC_Template->fetchPage()\n#11 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/AppFramework\/Http\/Dispatcher.php(114): OCP\\AppFramework\\Http\\TemplateResponse->render()\n#12 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/AppFramework\/App.php(115): OC\\AppFramework\\Http\\Dispatcher->dispatch(Object(OCA\\Files\\Controller\\ViewController), 'index')\n#13 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/AppFramework\/Routing\/RouteActionHandler.php(47): OC\\AppFramework\\App::main('ViewController', 'index', Object(OC\\AppFramework\\DependencyInjection\\DIContainer), Array)\n#14 [internal function]: OC\\AppFramework\\Routing\\RouteActionHandler->__invoke(Array)\n#15 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/Route\/Router.php(297): call_user_func(Object(OC\\AppFramework\\Routing\\RouteActionHandler), Array)\n#16 \/srv\/www\/clouddev.company.org\/htdocs\/lib\/base.php(999): OC\\Route\\Router->match('\/apps\/files\/')\n#17 \/srv\/www\/clouddev.company.org\/htdocs\/index.php(37): OC::handleRequest()\n#18 {main}","File":"\/srv\/www\/clouddev.company.org\/htdocs\/lib\/private\/Files\/Node\/File.php","Line":122}",
"app" : "index"
}

I've traced down that the reason was that $folder->getDirectoryListing() in SCSSCacher::resetCache() returned [""] for one entry. I think PHP resolved that to the document root.

I've fixed that by applying the following patch. However, since that seems to also fixed the failed directory listing, I'm not able to reproduce the problem again.

--- a/htdocs/lib/private/Template/SCSSCacher.php	Thu Apr 26 17:42:42 2018 +0200
+++ b/htdocs/lib/private/Template/SCSSCacher.php	Thu Apr 26 17:58:27 2018 +0200
@@ -266,7 +266,9 @@
 		$appDirectory = $this->appData->getDirectoryListing();
 		foreach ($appDirectory as $folder) {
 			foreach ($folder->getDirectoryListing() as $file) {
-				$file->delete();
+				if (!empty($file)) {
+					$file->delete();
+				}
 			}
 		}
 	}

Steps to reproduce

1. Don't now.... :-/

Expected behaviour

Nextcloud starts after upgrade

Actual behaviour

Nextcloud fails because SCSSCached tried to delete a file called "".

Server configuration

Operating system: Debian 9

Web server: Apache 2.9

Database: MariaDB 10.1

PHP version: 7.0

Nextcloud version: 13.0.2

Updated from an older Nextcloud/ownCloud or fresh install: Upgraded from 13.0.0 to 13.0.2

[Cybso]

I think these reports described the same problem:

• https://help.nextcloud.com/t/internal-server-error-after-upgrade-to-nextcloud-13/28127
• https://help.nextcloud.com/t/nextcloud-update-bleibt-haengen/20836/5

[MorrisJobke]

cc @juliushaertl @skjnldsv

[juliusknorr]

I think PHP resolved that to the document root.

@Cybso Any other hints for that? From the code it should actually throw a completly different error when [""] is returned by getDirectoryListing, since it would not be able to call the delete-method on a string.

I've traced down that the reason was that $folder->getDirectoryListing() in SCSSCacher::resetCache() returned [""] for one entry.

@rullzer Any idea why this could happen for the AppData?

[Cybso]

I tried to restore the previous state from the backup and repeat what I did yesterday, but whatever I do I am not able to reproduce this error.

However, I think the patch listed above has nothing to do with the problem getting fixed. It is useless, because if $file was empty the call to $file->delete() would have resulted in a NullPointerException, not in a NotPermittedException.

I think I accidentally "fixed" the problem when I tried to get the file's names with this code:

        try {
            $file->delete();
        } catch(NotPermittedException $e) {
            $this->logger->error('SCSSCacher: unable to drop cached file: ' . $file);
        }

This lead to the following entry in nextcloud.log:

"message":"SCSSCacher: unable to drop cached file: "

I have interpreted this as meaning that $file contains an empty string, overlooking that it is an object, and added the if(empty($file)) code. However, the try..catch code caused resetCache() to go through completely, and I think that eventually caused the SCSS cache to work again.

[juliusknorr]

However, the try..catch code caused resetCache() to go through completely, and I think that eventually caused the SCSS cache to work again.

That could be it. @Cybso Mind to open a PR to add the try/catch block, since the code should not fail hard there in my oppinion.

[Cybso]

I've used logException instead of error so the stack trace is preserved. Also, I've added the file's name to the error message because as far as I see no File object implements __toString().

[MorrisJobke]

Fixed in #9352