PROPFIND causes Error: Call to a member function getCache() on null #3110
Comments
despens
changed the title
|
@icewind1991 please have a look. server/apps/files_sharing/lib/Cache.php Line 62 in 6c11c54 |
|
Had just upgraded to 11.0.1 and found some users getting the same error. When running |
|
Any hint what is the problem here? I encountered the same problem after upgrading to version 11.0.1. |
|
Something with the file cache or user's files. We've rolled back our installation now. Something you could try and clear the file cache table in the database and run a full file scan. Take a backup first!!! |
|
We rolled back our installation, too. I have encountered a problem with legacy storages as discussed here. I had to fix the problem manually. Maybe the legacy storages cause this error? |
|
Thanks for the link to that discussion. Indeed, in my Would it help if I manually changed these entries to |
|
@despens I resolved the issue for my installation! 😄 Here is what I have done:
I think this is more a quick'N'dirty solution but it worked for me. Btw: nextcloud's database layout would benefit from some foreign keys ;) |
|
Thanks a ton, I will try this! Indeed this is missing from my bug-report: I did move the main storage directory to another place. Since this is a config file option, I had no idea there would be any absolute paths in the database and didn't think it was worth mentioning. It would be great if there was a tool in nextcloud that would take care of moving legacy storage locations to the updated format. |
|
@despens I did exactly the same thing - moved the main storage directory. The problem is already known. There is a migration step for this issue in owncloud. You can see it in the I removed the After that, I repaired my installation manually. Maybe you can just fix the |
|
@icewind1991 please have a look. |
|
My table MariaDB [nextcloud]> update oc_filecache set storage=11 where storage = 1;
ERROR 1062 (23000): Duplicate entry '11-d41d8cd98f00b204e9800998ecf8427e' for key 'fs_storage_path_hash'So I wonder if there is a way to start again and have nextcloud scan the users' directories without any assumptions being made? This is quite frustrating. 😞 |
|
@despens You cannot simply replace the storage id because this would yield duplicates (as mentioned in the error message). You can try my proposed procedure. You have to fix the |
|
Hey @f3anaro, I have difficulties following your procedure. I would have to translate storage ids like this: MariaDB [nextcloud]> select item_source, item_target, file_source from oc_share limit 10;
+-------------+-------------+-------------+
| item_source | item_target | file_source |
+-------------+-------------+-------------+
| 181969 | /181969 | 181969 |
| 206443 | /206443 | 206443 |
| 207146 | /207146 | 207146 |
| 207161 | /207161 | 207161 |
| 207158 | /207158 | 207158 |
| 207149 | /207149 | 207149 |
| 207141 | /207141 | 207141 |
| 207155 | /207155 | 207155 |
| 207138 | /207138 | 207138 |
| 207152 | /207152 | 207152 |
+-------------+-------------+-------------+I would be grateful for any further help. Are you on the nextcloud IRC channel? |
|
@despens Sry, I am from Germany - so we have a little bit shifted schedules ^^ You have to find the corresponding fileids in SELECT oc_share.id AS share_id,
old_cache.fileid AS old_fileid,
new_cache.fileid AS new_fileid,
old_cache.path
FROM oc_share
INNER JOIN oc_filecache AS old_cache ON oc_share.file_source = old_cache.fileid
-- Find the fileid of the cache entries with the 'home::$username' storage
INNER JOIN oc_filecache AS new_cache ON old_cache.path = new_cache.path
INNER JOIN oc_storages ON
new_cache.storage = oc_storages.numeric_id
AND oc_storages.id LIKE 'home::%'
-- select only legacy storages
WHERE old_cache.storage IN (
SELECT numeric_id FROM oc_storages WHERE id LIKE 'local::%'
)Maybe you have to create the new You can update the UPDATE oc_share
SET file_source = subquery.new_fileid,
item_source = subquery.new_fileid,
-- Attention!
-- This takes not into account if item_target was previously NULL.
-- You have to construct an IF-like statement for that.
-- In my case, I overwrote all previous values with the concatentation
item_target = CONCAT('/', subquery.new_fileid)
FROM (
SELECT oc_share.id AS share_id,
old_cache.fileid AS old_fileid,
new_cache.fileid AS new_fileid,
old_cache.path
FROM oc_share
INNER JOIN oc_filecache AS old_cache ON oc_share.file_source = old_cache.fileid
-- Find the fileid of the cache entries with the 'home::$username' storage
INNER JOIN oc_filecache AS new_cache ON old_cache.path = new_cache.path
INNER JOIN oc_storages ON
new_cache.storage = oc_storages.numeric_id
AND oc_storages.id LIKE 'home::%'
-- select only legacy storages
WHERE old_cache.storage IN (
SELECT numeric_id FROM oc_storages WHERE id LIKE 'local::%'
)
) AS subquery
WHERE id = subquery.share_idYou can do a similar thing with the |
|
Thanks @f3anaro — now I know how to proceed! |
|
@f3anaro thank you for query. My nextcloud 11.0.1 has some problem I test the SELECT before run update. It return 0 rows. :(
I can not understand how to proceed |
|
@marcochiodo The two conditions do not exclude each other because we are doing a double
Have you checked if your Maybe you have to create the |
|
You are right ;) I'm watching for This is content of "id" "numeric_id" "available" "last_checked" |
|
I am rather uncomfortable writing this, and perhaps this is the wrong place, but: I seem to have the very same problem, have had issues with a moved data directory in the past but somehow, after a lot of semi-knowledgeable hacking got Owncloud to upgrade from 7 to 8 to 9, and now have that problem after migrating this installation (as a test clone) to Nextcloud and updating to version 11. I may have read everything concering that problem BUT I fail to finally get my head around it. I guess it would not be possible to produce a step-by-step documentation regarding this seemingly not-so-rare and very annoying issue? |
|
@4001982248998 I do not think a step-by-step guide is advisable here because - as I mentioned above - my work around is a dirty hack in underlying database. Another thing you could try: Replace all legacy storage entries containing the old filesystem path with the appropriate new filesystem path. You can get all legacy storages with: SELECT id FROM oc_storages WHERE id LIKE 'local::%'; |
|
dirty or beautifully, I don't really care, as long as it works… I also tried simply deleting them (this is a snapshotted test system), but this also does not help overcome the files-scan: |
|
|
I am too dense for this. |
|
Well you could try to check which entries in |
|
I believe this has been fixed with f2e981e |
|
This patch is indeed looking very good, because now the scan does not cancel the process. Now it continues until all user's files have been scanned. Thumbs up! |
|
After upgrading to 11.0.3, I had to re-apply the patch. |
|
Hi, In the log files, I see this error: "Call to a member function getCache() on null at /var/www/web07/web/apps/files_sharing/lib/Cache.php#69" This particular install has been around a long time, since OwnCloud v 3 or something. It was moved onto our servers and into our control a couple of years ago. I know we've had problems with the 'local::' storage entries in the past. It looks like it's the user accounts that have been around for the longest who are experiencing this problem, so it is likely related to the storage ids in the database. I have tried applying f2e981e as recommeded above, but that doesn't appear to have solved the problem for me. The same getCache() error comes up when I run something like 'occ files:scan username' for one of the user accounts in question. Here's the stack trace: I was able to use a stack trace in order to get the file ID apparently causing the problem. That file belongs to a storage id of 'home::karen'. It doesn't seem to have anything to do with any of the 'local::' entries in the oc_storages table. In fact, there is only one 'local::' entry left in the oc_storages table now, which points to the install's data directory ('local::/var/www/web07/web/data/'). However, there are various oc_storages IDs with hex values. Anyone have any suggestions? It would be great if I could get this sorted out. I'm willing to try and follow the stack trace to figure out why this particular file is causing the problem. But first I thought I'd check and see if there are any other suggested fixes. Many thanks, |
Similar stacktrace here. In my case the following command helped: I got to that solution after running The interesting bit is stack frames 11/12. It looks like the scanner tries to check whether the storage is valid (i.e. it checks whether it is not failed) but that check actually triggers the error :/ Lucky enough the faulty |
|
I ran into the same thing @znerol described (running nc version 11.0.2.7). |
|
Thanks for your reply @icewind1991 |
|
f2e981e should already be backported to 11, the patch should apply cleanly on 11 |
|
Worked for me. Thanks! |
|
I did a lot of manual cleanup of the NC database in order to get around this problem. While I do have backups, it wouldn't be easy for me to setup a clone of the NC in order to test. So, I'm afraid I'm probably not going to be much help in terms of testing... |
Steps to reproduce
Expected behaviour
Directory of current user should be displayed.
Actual behaviour
Windows stays empty, error message displayed: This directory is unavailable, please check the logs or contact the administrator
Server configuration
Operating system: Ubutu 16.04
Web server: Apache
Database: MariaDB
PHP version: 7
Nextcloud version: 11.0.1
Updated from an older Nextcloud/ownCloud or fresh install: updated from 11
Where did you install Nextcloud from: updater app
Signing status:
Signing status
List of activated apps:
App list
The content of config/config.php:
Config report
Are you using external storage, if yes which one: sftp
Are you using encryption: no
Are you using an external user-backend, if yes which one: none
Client configuration
Browser: "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0"
Operating system:
Logs
Web server error log
Web server error log
``` [Mon Jan 16 07:35:03.753368 2017] [mpm_prefork:notice] [pid 29689] AH00163: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g configured -- resuming normal operations [Mon Jan 16 07:35:03.753412 2017] [core:notice] [pid 29689] AH00094: Command line: '/usr/sbin/apache2' ```Nextcloud log (data/nextcloud.log)
Nextcloud log
Browser log
Browser log
The text was updated successfully, but these errors were encountered: