Occ files:transfer-ownership does not move anything

ℹ️ Support
1

Nextcloud version: 12.0.3
Operating system and version: CentOS 7.4
Apache version: 2.4.6
PHP version: 7.1.14

The issue you are facing:

I want to move all files from user1 to user2, so I do:

$ ./occ files:transfer-ownership user1 user2
Analysing files of user1 ...
5179 [============================]
Collecting all share information for files and folder of user1 ...
3 [============================]
Transferring files to user2/files/transferred from user1 on 2018-07-09 15-38-56 ...
Restoring shares ...
Share with id 198 points at deleted file, skipping
1/3 [=========>------------------]  33%Share with id 316 points at deleted file, skipping
2/3 [==================>---------]  66%Share with id 317 points at deleted file, skipping
3/3 [============================] 100%
$

First the errors regarding shares with ids 198, 316, 317: I dont know which ones that are or how to find out.

Second, not a single file is moved, in contrast to the output indicating it did something. I check the sizes to see:

$ du -sm user1 user2
12519   user1
0       user2
-bash-4.2$

The WebUI for user2 confirms this by showing nothing.

Is this the first time you’ve seen this error?: yes - and the first time I use files:transfer-ownership

Steps to replicate it:

  1. do the above command

The output of your Nextcloud log in Admin > Logging:

nothing is logged at the time of this command.

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

<?php
$CONFIG = array (
  'passwordsalt' => 'AAAAAA',
  'secret' => 'BBBBB',
  'trusted_domains' => 
  array (
    0 => 'localhost',
    2 => 'cloud.domain.tld',
  ),
  'datadirectory' => '/srv/www/nextcloud/data',
  'overwrite.cli.url' => 'http://localhost',
  'dbtype' => 'pgsql',
  'version' => '12.0.3.3',
  'dbname' => 'nextcloud',
  'dbhost' => '127.0.0.1',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'nextcloud',
  'dbpassword' => 'bbbbbbbbbb',
  'logtimezone' => 'UTC',
  'installed' => true,
  'instanceid' => 'aaaaaaaaa',
  'user_backends' => 
  array (
    0 => 
    array (
      'class' => 'OC_User_IMAP',
      'arguments' => 
      array (
        0 => '{imap.host.domain.tld:993/imap/ssl}',
      ),
    ),
  ),
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'enable_previews' => 'false',
  'mail_smtpmode' => 'smtp',
  'mail_smtphost' => 'smtp.host.domain.tld',
  'mail_smtpsecure' => 'tls',
  'mail_smtpauth' => 1,
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpname' => 'mailuser@smtp.host',
  'mail_smtppassword' => ****',
  'mail_from_address' => 'nextcloud',
  'mail_domain' => 'domain.tld',
  'maintenance' => false,
  'loglevel' => 2,
  'mail_smtpport' => '587',
);

The output of your Apache/nginx/system log in /var/log/____:

nothing is logged at the time of this command.

2

investigating the Share with id XYZ points at deleted file, skipping messages shows that these are all shares owned by user1.

The message is wrong: none points to a deleted file, each points to a existing directory with data in it.

Deleting the shares does not make files:transfer-ownership transfer any files, contrasting its output.

3

workaround with the downside of losing all shares is:

rsync -av user1 user2
occ files:scan user2

user1/ can be removed after that. User2 needs to re-create shares, get new quota settings, etc …

To me files:transfer-ownership is totally broken.

4

This is still not working in 14.0.7

5

I’m still seeing this in 15.0.2.

6

Hey folks,

I think I found the solution to this issue!
It drove me CRYZY until I started to trace the error down through its numerous stages:

  • At first, it quickly turned out that the call $view->rename($this->sourcePath, $this->finalTarget); in apps/files/libs/Command/TransferOwnership.php returned false, so it was actually reporting that moving the directory was failing, but the CLI script did not check the return (Turns out to be the actual bug here…).
  • Next, I tried to figure out why on earth the move operation was not succeeding. Finally, after tracing the “false” return all the way down to the storage wrapper class, I ended up in lib/private/Files/Storage/Wrapper/Quota.php where I found this:
public function moveFromStorage(IStorage $sourceStorage, $sourceInternalPath, $targetInternalPath) {
    $free = $this->free_space($targetInternalPath);
    if ($free < 0 or $this->getSize($sourceInternalPath, $sourceStorage) < $free) {
        return $this->storage->moveFromStorage($sourceStorage, $sourceInternalPath, $targetInternalPath);
    } else {
        return false;
    }
}

And yep, that’s it: I forgot to check that the target user has enough storage quota to hold all the data moved from the source user!

Time to get up and hit my head against something solid…

It’s not unlikely that some if not all of you stumbled upon the same mistake, so I hope this helps some people… Meanwhile, I’m going to open an issue for this.