Moving of shared directory not working

Nextcloud version (eg, 20.0.5): 22.2.0.2
Operating system and version (eg, Ubuntu 20.04): Debian 10.11
Apache or nginx version (eg, Apache 2.4.25): nginx 1.14.2
PHP version (eg, 7.4): 7.4

The issue you are facing:
After trying to move a shared folder, the error occurs that the folder cannot be moved.
But, the size of the folder is shown now as ‘Pending’ and if I try to access the folder, I get returned back to main page.
In the target location of the movement, the folder isn’t there eiter.

I just checked the data folder, there it seems like it has been moved correctly.
Seems for me like a database problem.

Is this the first time you’ve seen this error? (Y/N): Y

The output of your Nextcloud log in Admin > Logging:

[webdav] Fatal: An exception occurred while executing a query: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction

MOVE /remote.php/dav/files/xXx/XXX
from 162.158.90.243 by xXx at 2021-11-20T15:25:40+00:00

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'xxx',
  'passwordsalt' => 'xxx',
  'secret' => 'xxx',
  'trusted_domains' => 
  array (
    0 => '10.8.0.1',
    2 => '127.0.0.1',
  ),
  'datadirectory' => '/media/nextData',
  'skeletondirectory' => '',
  'dbtype' => 'mysql',
  'version' => '22.2.0.2',
  'overwrite.cli.url' => 'xxx',
  'dbname' => 'xx',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'xxx',
  'dbpassword' => 'xxx',
  'installed' => true,
  'mysql.utf8mb4' => true,
  'maintenance' => false,
  'appstoreenabled' => true,
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'technik',
  'mail_domain' => 'xxx',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtphost' => 'xxx',
  'mail_smtpport' => '465',
  'mail_smtpname' => 'xxx',
  'mail_smtppassword' => 'xxx',
  'mail_smtpdebug' => true,
  'default_language' => 'de',
  'default_locale' => 'de_DE',
  'default_phone_region' => 'DE',
  'twofactor_enforced' => 'false',
  'twofactor_enforced_groups' => 
  array (
  ),
  'twofactor_enforced_excluded_groups' => 
  array (
    0 => 'admin',
  ),
  'ldapIgnoreNamingRules' => false,
  'ldapProviderFactory' => 'OCA\\User_LDAP\\LDAPProviderFactory',
  'loglevel' => 2,
  'theme' => '',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'encryption.key_storage_migrated' => false,
);

Any Ideas to get this folder working again?

Perhaps you can scan all files again.

sudo -u www-data php occ files:scan --all

Perhaps also you can run

sudo -u www-data php occ maintenance:repair

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/occ_command.html

1 Like

Thank you, the folders are now correct again.
But the files are corrupted and all starts with this part (for example .ods files for collabora):

HBEGIN:oc_encryption_module:OC_DEFAULT_MODULE:cipher:AES-256-CTR:signed:true:HEND

Any ideas how to get the files repaired?

I think the files are server sided encrypted. Have you activated this?

I don’t think I changed anything since the problem above occurred - how can I check/validate the encryption?

EDIT: Files in other folders are working correct.

Please test if encryption is activated:
https://www.techrepublic.com/article/how-to-enable-server-side-encryption-in-nextcloud/

Read also
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/encryption_configuration.html

If yes post it. Then we must find a way to deactivate it again.

Yep seems enabled:
image

But shouldn’t be all files facing that problem and not only the one in that folder?

Perhaps it was accidentally activated and the process went wrong.

There is only a security advantage with server-side encryption if you use external storage. You can the the internet to deactivate this. But i do not know if it works if not all files are encrypted.

So you mean I should disable the module for testing purposes if the files are readable then?

No. But there must be a possiblity to go back to not encryption or you must use the encryption correctly.

i just found this one: Decryption corrupted all files — serious file loss · Issue #8311 · nextcloud/server · GitHub
Maybe I should try that?

EDIT:
I just selected the encrypted value from the database:
SELECT encrypted FROM oc_filecache WHERE fileid = 90456; (fileid found in the url while trying to access the file in nextcloud).
This results in 0.

After that, I run UPDATE oc_filecache SET encrypted = 1 WHERE fileid = 90456;
Now, the file is accessible.

Thanks for your help!