Ref https://sentry.rullzer.com/share/issue/ac63b1dfba0d4208a037af96b7919a3c/
Error: Call to a member function getMimetype() on boolean
File "files_sharing/lib/Controller/RemoteController.php", line 120, in extendShareInfo
$share['mimetype'] = $info->getMimetype();
File "files_sharing/lib/Controller/RemoteController.php", line 0, in array_map
OCA\Files_Sharing\Controller\RemoteController::extendShareInfo
File "files_sharing/lib/Controller/RemoteController.php", line 138, in getShares
$shares = array_map('self::extendShareInfo', $shares);
File "/var/www/html/lib/private/AppFramework/Http/Dispatcher.php", line 166, in executeController
$response = \call_user_func_array([$controller, $methodName], $arguments);
File "/var/www/html/lib/private/AppFramework/Http/Dispatcher.php", line 99, in dispatch
$response = $this->executeController($controller, $methodName);
...
(5 additional frame(s) were not displayed)
cc @nextcloud/sharing
GitMate.io thinks possibly related issues are https://github.com/nextcloud/server/issues/6803 (Nextcloud 12 throwing fatal error: cron - “Call to a member function getFileInfo() on null”), https://github.com/nextcloud/server/issues/3110 (PROPFIND causes Error: Call to a member function getCache() on null), https://github.com/nextcloud/server/issues/9953 (Error message "Call to a member function getUID() on null" in cron), https://github.com/nextcloud/server/issues/6706 (Call to a member function getUID() on null), and https://github.com/nextcloud/server/issues/195 (php: Call to a member function getUID() on a non-object / trashbin.php).
GitMate.io thinks possibly related issues are #6803 (Nextcloud 12 throwing fatal error: cron - “Call to a member function getFileInfo() on null”), #3110 (PROPFIND causes Error: Call to a member function getCache() on null), #9953 (Error message "Call to a member function getUID() on null" in cron), #6706 (Call to a member function getUID() on null), and #195 (php: Call to a member function getUID() on a non-object / trashbin.php).
@nextcloud-bot nope.
It looks like this happens if a remote file is in the db but not existing any more in real.
I'm not sure how the system should behave? Just sending a "not found"?
Let's look into this for 15.0.1
Still valid @ChristophWurst ?
I have no idea
I have no idea
It still happens occasionally: https://sentry.nextcloud.com/share/issue/79b6cb6f432f45399cffeb4bb20342fe/
Just an update from my side - 16.0.1 reports this when I try to share from another nextcloud server.
Server A: 16.01
Server B: 15.0.5. Share folder to Server A
Server A: Accept share. Error is reported as suggested in topic:
Error: Call to a member function getMimetype() on bool at /var/www/nextcloud/apps/files_sharing/lib/Controller/RemoteController.php#120
This suggests that the call to get the $info is returning 0/false??
$info = $view->getFileInfo($share['mountpoint']);
Is there anything in your nextcloud.log when that happens? There is a line that should log when the storage is invalid: \OC::$server->getLogger()->warning('Storage not valid for mountpoint: ' . $mount->getMountPoint());
The fileinfo will be false in that case.
Nothing shows in my log file other than the error I mentioned. I'll set up another server to allow me to add some debugging into the PHP (I can't do this on my live server).
I'll keep you posted to see what I find.
Nothing shows in my log file other than the error I mentioned. I'll set up another server to allow me to add some debugging into the PHP (I can't do this on my live server).
I'll keep you posted to see what I find.
Did you fix this Problem?
Index: apps/files_sharing/lib/Controller/RemoteController.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- apps/files_sharing/lib/Controller/RemoteController.php (revision 1a7310f4b34a6665ced59b6e1d2a0598243462d9)
+++ apps/files_sharing/lib/Controller/RemoteController.php (date 1567945248445)
@@ -117,6 +117,10 @@
$view = new \OC\Files\View('/' . \OC_User::getUser() . '/files/');
$info = $view->getFileInfo($share['mountpoint']);
+ if ($info === false) {
+ \OC::$server->getLogger()->debug('Could not fetch file info for mount point: ' . $share['mountpoint'], ['share' => $share]);
+ }
+
$share['mimetype'] = $info->getMimetype();
$share['mtime'] = $info->getMTime();
$share['permissions'] = $info->getPermissions();
Mind to alter the code and add some more insights? Please ensure that 'debug' => true, in your config.php to log debug messages.
Nothing shows in my log file other than the error I mentioned. I'll set up another server to allow me to add some debugging into the PHP (I can't do this on my live server).
I'll keep you posted to see what I find.
Exactly same here - Nextcloud 16.0.5.
Accept a remote share and it don't appear in list but this error. Tried creating the folder - of course it does not work 'cause internal it exists from a share. No other error messages, tried output like comment above, but seems getFileInfo returns "true" not false.
Other server is 16.0.5, too. It is annoying. Don't know when it stopped working - in earlier versions it worked.
@Messinger could you add the debug statement? https://github.com/nextcloud/server/issues/10585#issuecomment-529197724
@kesselb did. And yes, "Could not fetch file info for mount point:" messages appears
@kesselb tracked a bit down. It fails in lib/private/Files/View.php lines 1382 - 1384.
$data = $this->getCacheEntry($storage, $internalPath, $relativePath);
if (!$data instanceof ICacheEntry) {
return false;
}
GetCacheEntry returns a OC\Files\View Object and not a ICacheEntry. This happens for a lot of files btw.
But at this point I'm out 'cause I'm not that deep in Nextcloud code/workflow to understand the difference.
"Could not fetch file info for mount point:" messages appears
Mind to share the complete message?
It's possible to have different cache implementations for storage types. Maybe there is a faulty cache that returns a wrong object.
Index: lib/private/Files/View.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- lib/private/Files/View.php (revision 2507f26428873e12976c9e3b9e0a0fb7d8429fdd)
+++ lib/private/Files/View.php (date 1570271980188)
@@ -1348,6 +1348,10 @@
// if the file is locked we just use the old cache info
}
+ if ($data instanceof View) {
+ \OC::$server->getLogger()->debug('$data instanceof View. data: ' . print_r($data, true) . ' cache: ' . get_class($cache));
+ }
+
return $data;
}
Should log the data and type of cache object in such a case.
wrote it as
if (!$data instanceof ICacheEntry) {
\OC::$server->getLogger()->debug('$data instanceof View. data: ' . print_r($data, true) . ' cache: ' . get_class($cache));
}
and resulted in
[no app in context] Debug: $data instanceof View. data: cache: OCA\Files_Sharing\External\Cache
@kesselb yep, checked. OCA\Files_Sharing\External\Cache is an instance of Wrapper and therefore from various Storage drivers. But not cache.
I think there is workflow problem with external shares in Nextcloud. And don't know since when. Since when it is required to be a ICacheEntry?
Index: lib/private/Files/View.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- lib/private/Files/View.php (revision 2507f26428873e12976c9e3b9e0a0fb7d8429fdd)
+++ lib/private/Files/View.php (date 1570283078659)
@@ -1348,6 +1348,10 @@
// if the file is locked we just use the old cache info
}
+ if (!($data instanceof ICacheEntry)) {
+ \OC::$server->getLogger()->debug('$data instanceof View. data: ' . get_class($data) . ', cache: ' . get_class($cache) . ', storage: ' . get_class($storage));
+ }
+
return $data;
}
Could you post some logs with the above debug code?
@kesselb here we go:
$data instanceof View. data: , cache: OCA\Files_Sharing\External\Cache, storage: OCA\Files_Trashbin\Storage
Don't understand why Trashbin... (I watch as user the "Shares" -> "Shared with you" area not the global files area). I'd check it twice but really, this comes when it tries to get information about my remote.
Index: lib/private/Files/View.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- lib/private/Files/View.php (revision 2507f26428873e12976c9e3b9e0a0fb7d8429fdd)
+++ lib/private/Files/View.php (date 1570296238220)
@@ -1348,6 +1348,10 @@
// if the file is locked we just use the old cache info
}
+ if (!($data instanceof ICacheEntry)) {
+ \OC::$server->getLogger()->debug('$data instanceof View. data: ' . var_export($data, true) . ', cache: ' . get_class($cache) . ', storage: ' . get_class($storage));
+ }
+
return $data;
}
Could you describe $data? Have you removed the information for privacy reason? This debug code should print a bit more about data. Trashbin is fine. Its a wrapper for a storage backend. If you delete a file the storage backend will delete the file. Is the storage wrapped into a trashbin_storage the file is moved to trashbin first. Like this you can add additional features to the storage layer without changing the actual storage code. Its like a https://en.wikipedia.org/wiki/Matryoshka_doll ;)
no, data is empty, I did not remove anything from log. Yes, I was wondering about, too
Also with the above code? var_export should print the type (string, int, object, etc.) at least.
Also with the above code? var_export should print the type (string, int, object, etc.) at least.
slap had an error. $data has value false
EDIT:
$data instanceof View for /remote_shared_folder: data: false, cache: OCA\Files_Sharing\External\Cache, storage: OCA\Files_Trashbin\Storage
tried and read a while around, but got a question: is it possible that nextcloud has problmes with letsencrypt certificates on remotes?
OCP\Files\StorageNotAvailableException: Sabre\HTTP\ClientException: server certificate verification failed. CAfile: /var/www/YYY/<user_xxx>/files_external/rootcerts.crt CRLfile: none
whatever this means - checked, there is a rootcerts.crt inside the folder, whoever stored it there. But it looks like nextcloud can not retrieve remote information thats why inserting fails
See #17427
after adding Letsencrypt root certificate to nextcloud instances (16.0.5!!!!!!!) it works. Tnx for your patience.
OK. I can reproduce it with self-signed certificates. To summarize:
1) Share a file from instance A to instance B.
2) Accept the share.
3) Invalidate the certificates to disrupt the connection (e.g. Remove the self-signed ca from instance B).
4) See Call to a member function getMimetype() on boolean in the logs.
Technical flow:
1) Request RemoteController::getShares or RemoteController::getShare.
2) Have a share in the local database.
3) Try to fetch more information RemoteController::extendShareInfo.
getFileInfo return false if the remote server is unreachable. We don't handle this case now and call getMimetype on false.
It looks like this happens if a remote file is in the db but not existing any more in real. I'm not sure how the system should behave? Just sending a "not found"?
That's the question ;) If we return the share without the additional data the share is visible but most of the actions (e.g. show details) will fail. If the share is hidden there is no way to remove this broken share.
cc @nextcloud/server-triage isn't there any logic for unreachable shares?
@kesselb for failing remote shares, the only logic is if we get a 404, where we delete the share.
Other than that, we just ignore it if it's failing I think.
@rullzer @nickvergessen @schiessle ?
getFileInfo return false if the remote server is unreachable. We don't handle this case now …
So that is what we could fix :)
I have some further info if this helps, and I've had to jump through some hoops in order to get my share working between my NC (we'll call Server A, running 16.0.5) and a remote NC (we'll call Server B, running 16.0.1).
Sequence of events used:
The downside, is that I do not have access to Server B, and nor should I need it. The problem for me is that NC is presenting the wrong share link from Server B, indicating either a config set up error on that server, or a genuine bug somewhere.
Hope this helps.