Issues deleting my folders and files on an encrypted profile (OC10.x)


#1

Steps to reproduce

  1. I try to delete a file or a folder, and I just get the error “xxx could not be deleted”
  2. I can’t find any informations about the problem in the logs, or I am just missing it.
  3. Other profiles do not have that problem. Is there a way to clean it up specifically for my own profile?

Expected behaviour

The files and directories should be gone, but it doesn’t seem to work at all.

Actual behaviour

Files won’t be deleted. Yet an upload seem to be possible.

Server configuration

Linux

Web server:
Apache 2.4

Database:
MySQL 5.6
PHP version:
7.1
ownCloud version: (see ownCloud admin page)
10.1.x

Updated from an older ownCloud or fresh install:
Updated from 7 > 10

Where did you install ownCloud from:
Tar.gz

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

Are you using external storage, if yes which one: local/smb/sftp/…

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/…

LDAP configuration (delete this part if not used)

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your ownCloud installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

Client configuration

Browser:

Operating system:

Logs

Web server error log

Insert your webserver log here

ownCloud log (data/owncloud.log)

Insert your ownCloud log here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

#2

10.1.x has not been released yet. How did you get a copy? O_o

Also - do you have file locking enabled? Memcache or Redis


#3

Sorry, I meant 10.0.x :wink:
To be more exact: ownCloud 10.0.7 (stable)
I had file locking enabled, but I did remove all the configurations for that again.
And it was Memcache, and I wanted to try Redis.


#4

Could you post your config.php and tell me what kind of encryption you have? Masterkey or userkey?

Also you have mentioned something about this behavior not being the same for all users. What user has this problem and what other users do you have?


#5

It could be possible that its not related but personally i would still:

  1. Update to the latest ownCloud 10.0.8 release
  2. Fix the integrity warning by deleting the EXTRA_FILEs and rescanning the installation as explained in the docs

#6

That’s my config.php

<?php
$CONFIG = array (
  'instanceid' => 'ocpgii6gb1bd',
  'passwordsalt' => 'xxxx',
  'datadirectory' => '/var/www/localhost/owncloud/data',
  'dbtype' => 'mysql',
  'version' => '10.0.7.2',
  'dbname' => 'cloud',
  'dbhost' => '127.0.0.1',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'xxxxx',
  'dbpassword' => 'xxxxx',
  'installed' => true,
  'forcessl' => true,
  'maintenance' => false,
  'overwrite.cli.url' => '/owncloud',
  'ldapIgnoreNamingRules' => false,
  'loglevel' => 0,
  'theme' => '',
  'trusted_domains' => 
  array (
    0 => 'cloud.domain.net',
  ),
  'secret' => 'xxxxx',
  'share_folder' => '/Shared',
  'mail_from_address' => 'info',
  'mail_smtpmode' => 'php',
  'mail_domain' => 'domain.com',
  'trashbin_retention_obligation' => 'auto',
);

concerning the encryption: I guess I have masterkey, at least I did configure the masterkey in the admin area but I did that before upgrading to 10.0.x
About the users: All users are AD users and as I said, I just know that my user has that issue, but that user is one of largest filestores, while other with smaller filestores do not seem to have that issue.


#7

Hey, it seems you have posted some sensitive data like your database user, password, domain name, passwordsalt and secret of your config.php.

I think you should change this data on your installation ASAP. From what i have seen during my edits its not possible to remove such data from a post without keeping the history so just editing the post probably won’t help.


#8

Crab, you are right, thank you for notifying me.
I’ll change the details right away.


#9

@dmitry did you find anything in my config?


#10

Not really.

I have noticed that you have updated from ownCloud 7 to 10, is that right?

also this:

are the files stored locally or on an external storage?


#11

I’ve updated from 7 to 8 to 9 to 10 > 10.0.x
Currently all file stores are locally.


#12

Maybe you could still update to 10.0.8 or even to the upcoming 10.0.9 and issues like this are already solved?


#13

I’ll give it a try.
Eventhough I think, that it must be an issue which was due to the memcache/redis configuration attempt


#14

Maybe I found something. A occ repair gives me this:
apache@cloud ~/localhost/htdocs/owncloud $ ./occ files:scan --all --repair
0 [>---------------------------]

Scanning files for 15 users
Starting scan for user 1 out of 15 (2C6C3DAB-B6E1-4E9B-B8B7-298FB3695517)
Starting scan for user 2 out of 15 (4FDE5FBB-846C-4E18-B730-4903DD48A5F3)
Starting scan for user 3 out of 15 (797B499E-E3A2-470D-9FDF-392987CD14AF)
Starting scan for user 4 out of 15 (D4FB7ECC-8903-48AE-8034-DFAA8C3E0BD7)
Starting scan for user 5 out of 15 (E354B8F4-EBD0-4F32-A830-C487E9FBAA2F)
Starting scan for user 6 out of 15 (ED5E8E98-63D5-4B4B-BB9E-7FBEC837AF8A)
Starting scan for user 7 out of 15 (a.xxxxx)
Starting scan for user 8 out of 15 (xxxxx)
Starting scan for user 9 out of 15 (h.xxxxx)
Starting scan for user 10 out of 15 (xxxxxx)
Starting scan for user 11 out of 15 (p.xxxxxx)
Starting scan for user 12 out of 15 (s.fohler)
Exception during scan: OCP\Lock\LockedException: “files/cee97d5676d4a183c4636153c2bc758e” is locked
#0 /var/www/localhost/htdocs/owncloud/lib/private/Files/Storage/Common.php(653): OC\Lock\DBLockingProvider->acquireLock(‘files/cee97d567…’, 2)
#1 /var/www/localhost/htdocs/owncloud/lib/private/Files/Storage/Wrapper/Wrapper.php(589): OC\Files\Storage\Common->acquireLock(‘scanner::’, 2, Object(OC\Lock\DBLockingProvider))
#2 /var/www/localhost/htdocs/owncloud/lib/private/Files/Storage/Wrapper/Wrapper.php(589): OC\Files\Storage\Wrapper\Wrapper->acquireLock(‘scanner::’, 2, Object(OC\Lock\DBLockingProvider))
#3 /var/www/localhost/htdocs/owncloud/lib/private/Files/Storage/Wrapper/Wrapper.php(589): OC\Files\Storage\Wrapper\Wrapper->acquireLock(‘scanner::’, 2, Object(OC\Lock\DBLockingProvider))
#4 /var/www/localhost/htdocs/owncloud/lib/private/Files/Cache/Scanner.php(321): OC\Files\Storage\Wrapper\Wrapper->acquireLock(‘scanner::’, 2, Object(OC\Lock\DBLockingProvider))
#5 /var/www/localhost/htdocs/owncloud/lib/private/Files/Utils/Scanner.php(246): OC\Files\Cache\Scanner->scan(’’, true, 3)
#6 /var/www/localhost/htdocs/owncloud/apps/files/lib/Command/Scan.php(243): OC\Files\Utils\Scanner->scan(’/s.fohler’, false)
#7 /var/www/localhost/htdocs/owncloud/apps/files/lib/Command/Scan.php(389): OCA\Files\Command\Scan->scanFiles(‘s.fohler’, ‘/s.fohler’, false, Object(Symfony\Component\Console\Output\ConsoleOutput), false, false)
#8 /var/www/localhost/htdocs/owncloud/apps/files/lib/Command/Scan.php(354): OCA\Files\Command\Scan->userScan(Array, NULL, false, Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), false)
#9 /var/www/localhost/htdocs/owncloud/apps/files/lib/Command/Scan.php(319): OCA\Files\Command\Scan->processUserChunks(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), Array, NULL, false)
#10 /var/www/localhost/htdocs/owncloud/lib/composer/symfony/console/Command/Command.php(252): OCA\Files\Command\Scan->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#11 /var/www/localhost/htdocs/owncloud/core/Command/Base.php(159): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#12 /var/www/localhost/htdocs/owncloud/lib/composer/symfony/console/Application.php(946): OC\Core\Command\Base->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#13 /var/www/localhost/htdocs/owncloud/lib/composer/symfony/console/Application.php(248): Symfony\Component\Console\Application->doRunCommand(Object(OCA\Files\Command\Scan), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#14 /var/www/localhost/htdocs/owncloud/lib/composer/symfony/console/Application.php(148): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 /var/www/localhost/htdocs/owncloud/lib/private/Console/Application.php(161): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/localhost/htdocs/owncloud/console.php(106): OC\Console\Application->run()
#17 /var/www/localhost/htdocs/owncloud/occ(11): require_once(’/var/www/localh…’)
#18 {main}
Starting scan for user 13 out of 15 (xxxxxxx)
Starting scan for user 14 out of 15 (xxxxxxx)
Starting scan for user 15 out of 15 (xxxxxxx)

±--------±------±-------------+
| Folders | Files | Elapsed time |
±--------±------±-------------+
| 63997 | 89599 | 00:25:38 |
±--------±------±-------------+

Maybe that gives us a hint?


#15

found something on how to unlock locked files.


Owncloud Intergation with exsternal freenas storage
#16

@dmitry thank you for that hint. I’ve tried that, but the table oc_file_locks does not have any content according to the “select * from oc_file_locks”. Yet the innodb table file shows >800 000 rows and 150MB data. Any idea what we can do about that?


#17

Could you try to install redis again, following the documentation, and see if the locks disappear?

If you don’t have redis, file locking is done by the database, the locks last for one hour.


#18

@dmitry I don’t have redis installed, and if it’s done by database, the locks I have are much longer then one hour. What triggers those logs, any idea about that?


#19

fine edits I suppose.

Could you try to install redis? it’s not that complicated :slight_smile:

Maybe that would fix your file locks.


#20

I can try it, but I think I wanted to do that in the first place and there was a showstopper for that.
Do you some good instructions, or howto guides for the REDIS usage in Owncloud?