8.1.1 + Encryption: Exception: {\"Message\":\"An exception occurred while executing 'INSERT INTO oc_filecache
#18502
Comments
|
@schiesbn any idea? |
|
I got this happening randomly as well on master with encryption enabled, uploading a folder with 70 pictures in it. Could be a race condition, but I don't see where. Maybe the cache update/propagation from the previous file isn't finished yet while the next file upload is trying to propagate too and touch the same entries. This should hopefully disappear when enabling transactional file locking: https://doc.owncloud.org/server/8.1/admin_manual/configuration_files/files_locking_transactional.html @Bobuscho does it happen randomly or always with the same files ? |
|
I tried with enabled transactional locking, but I'm still seeing the errors randomly. CC @icewind1991 |
|
I got this again and it seems the cache update succeeded, but wrote the wrong size. Having a file with the wrong size breaks the sync client when it tries to download it since it's waiting for more data that doesn't come (Connection closed). The question is why the cache update clash is happening in the first place. |
|
even when filesystem_check_changes is 0 |
|
Now I can't make the exception appear again, but I still get sync failures. Nothing in the log. 😦 |
|
Okay, so I got it again. But I suspect these might be different issues: |
|
I suspect it might be happening whenever the sync client tries to get the quota while an upload is in progress. |
|
The test above was without transactional locking on stable8.1 Now trying with transactional locking enabled on stable8.1 the exception with file cache doesn't want to reappear... |
|
Okay, looks like if I disable the debugger/breakpoint the second issue, the one with no logs, appears again. Also I saw this in the error_log: This is the bug from XDebug. So let's disable the debugger completely and retest with transactional file locking. |
|
Ok, with XDebug disabled I can't reproduce the issue with transactional locking enabled. The purpose of locking is to avoid random concurrency issues. @Bobuscho could you give it a try: https://doc.owncloud.org/server/8.1/admin_manual/configuration_files/files_locking_transactional.html and see if it solves the issue for you ? |
|
PVince81, thank you very much for your testing. I'll be back at home tomorrow or at Friday, so i will test it asap when i come home! Meanwhile i enabled the file locking and install redis etc, but i need some time to test it with encrypted data. |
|
I've enabled encryption and tried to sync a new folder with my 1Password files. The admin page states that file locking is enabled, redis is running fine. Sync still fails with output: Without encryption activated, everything runs fine. |
|
@icewind1991 @schiesbn looks like a double-locking issue ? |
|
PVince81, i am not sure. I disabled the external storage app and the error disappears and the files sync without any problems, even if encryption and locking is enabled. Maybe the external storage app causes the problem? |
|
Note that this is the flock based lockin app, not the new transitional locking |
|
Okay, i have tested another few things by disabling every Owncloud App one by one. Maybe this is useful to narrow down the cause of this error... Edit: Too soon...Error is still there: |
DescriptionWe sync 320.000,00 Documents with 107 GB. Expected behaviourSync all the files Actual behaviourDon't sync all the files 😞 Server configurationOperating system: Web server: Apache modules enabled as declared in: Database: PHP version: ownCloud version: Updated from an older ownCloud or fresh install: List of activated apps: The content of config/config.php: Are you using external storage, if yes which one: Are you using encryption: Are you using an external user-backend, if yes which one: No Client configurationSync-Client 2.0.1 and 1.8.4 (Just for testing) Operating system: LogsownCloud logs, server and client. apache logs @schiesbn I will ask about the testing you told on the phone. 00003788 |
|
@schiesbn I put the new log files with the patch you provided to me: S3-ownCloud\Shared\owncloud\support\github-issues\core\18502\NEW2 |
|
@schiesbn @PVince81 Your recomendation `filesystem_check_changes => 0;`` in the config.php sounds really good because with encryption is not needed to check all the time the data folder. After a few hours where not so many error, but this one seems weird:
@guruz @danimo Any clue? I'm trying to get the log file when the error happens again. |
|
@cdamken any matching server logs ? |
|
So far I uploaded successfully: I'm waiting for my customer for his feedback if for him did work fine too. |
|
Hi Guys, I confirmed with my customer: the If @Bobuscho doesn't have more information about it I would said that it is the solution. From my side it's solved. Thanks a lot! |
|
While this works with a workaround, we should fix this sometime. |
|
Yeah ok, but fix what? |
|
Still an exception with locking enabled: #18502 (comment) |
ghost
mentioned this issue
|
@felixboehm I have a similar problem, but not sure if it's the same, that has not been fixed with the "filesystem_check_changes => 0;"... |
|
Disabling the Encryption app doesn't solve the problem. Also disabling other apps (like files, external and locking, or dashboard, roundcube, tasks, contacts, calendar...) gives the same result. |
|
Any idea, anyone? I will have to do a fresh install from zero then... |
as you described, you erased the oc_filecache, that is not good. I think your problem is because the sqlite: 'dbtype' => 'sqlite3', |
|
I just erased the oc_filecache for testing, I have a backup of it and I restored it. Thanks. |
|
What's the state of this? I also get this error with a fresh install of 8.2.1 (using MySQL 5.1) and OSX sync client 2.1.0 on the first sync attempt (single user). The previous workaround of setting Also, what's the actual impact of this bug? |
|
@brevilo do you have a log with stack trace ? Could help finding out which code path led to this. With "filesystem_check_changes" set to 0 and transactional file locking enabled (default enabled in 8.2.x) this shouldn't happen any more. |
|
@PVince81 no, unfortunately not, and in the meantime I dropped server-side encryption (reinstalled ownCloud) because of this. Now using client-side encryption. No errors so far so this might indeed be a side-effect of using server-side encryption. |
|
I also ended reinstalling from zero my OwnCloud... |
|
Is this issue still valid? |
|
I guess so... As I said I had to reinstall from zero my ownCloud. |
|
Closing in favor of #25070. You might want to try changing the transaction isolation mode: https://doc.owncloud.org/server/9.0/admin_manual/configuration_database/linux_database_configuration.html?highlight=transaction#mysql-mariadb-with-binary-logging-enabled |
Steps to reproduce
Expected behaviour
Complete sync of the folders stated above
Actual behaviour
Client reports: "Connection closed/interrupted" (Vorgang abgebrochen)
Server configuration
Operating system:
Raspbian Wheezy
Web server:
Nginx 1.9.4
Database:
MySQL
PHP version:
5.4.41
ownCloud version: (see ownCloud admin page)
8.1.1
Updated from an older ownCloud or fresh install:
fresh install
List of activated apps:
Enabled:
The content of config/config.php:
Are you using external storage, if yes which one: local/smb/sftp/...
Google Drive
Are you using encryption: yes/no
Yes
Client configuration
Owncloud Sync Client
Operating system:
Windows 10
Log
ownCloud log (data/owncloud.log)
Webserver log (nginx.log) shows nothing but "an upstream response is buffered to a temporary file"...i don't know how to solve the problem...i own the server, permissions are set correctly, it seems to be an issue with the encryption module because on an unencrypted install, the error does not appear.
The text was updated successfully, but these errors were encountered: