Unable to transfer file ownership away from deleted ldap user

[oskarb]

Nextcloud version (eg, 12.0.2): 15.0.7
Operating system and version (eg, Ubuntu 17.04): 18.04
Apache or nginx version (eg, Apache 2.4.25): 2.4.29
PHP version (eg, 7.1): 7.2

The issue you are facing:
occ files:transfer-ownership fails for a user. The source user is an LDAP user that has been deleted from LDAP but the user is listed in "remnats" and the files are still there.

occ ldap:show-remnants list the user with Nextcloud name:
E4D4373C-DC55-40E5-85DF-718C96A09137

occ user:list does not list the user though.

The files folder exists on local disk:

$ sudo ls -l /var/www/nextcloud/data/E4D4373C-DC55-40E5-85DF-718C96A09137/files
total 6144
drwxr-xr-x 11 www-data www-data    4096 jun 20  2018  Customers
[more]

$ sudo du -hsc  /var/www/nextcloud/data/E4D4373C-DC55-40E5-85DF-718C96A09137/files
4,3G	/var/www/nextcloud/data/E4D4373C-DC55-40E5-85DF-718C96A09137/files

Despite this, the transfer ownership fails:

$ sudo -u www-data php /var/www/nextcloud/occ files:transfer-ownership -vvv \
    E4D4373C-DC55-40E5-85DF-718C96A09137 509FA19B-B1C3-4042-AA40-115C804C48B2
Unknown path provided: 

How can I transfer these files to a different user before I completely delete the old user?

[oskarb]

The removed user has a folder which is shared to a user that still exists. Since upgrading the Linux Nextcloud client to 2.5, that user's client fails to sync files, just saying that "A HTTP transmission error happened. The server file discover reply is missing data." I have determined that the detailed log complains about the folder shared from the user that has been deleted in LDAP. This is blocking all file sync for the affected user.

[kesselb]

Here are some examples for the transfer ownership command: #14051

I'm not sure if something is different with ldap 🤔

[kesselb]

sudo -u www-data php /var/www/nextcloud/occ files:transfer-ownership --path=/ E4D4373C-DC55-40E5-85DF-718C96A09137 509FA19B-B1C3-4042-AA40-115C804C48B2

[kesselb]

Hmm. We have a valid source user and a valid destination user but the source user is not a valid directory.

server/apps/files/lib/Command/TransferOwnership.php

Lines 142 to 145 in 30d8e3e

	if (!$view->is_dir($this->sourcePath)) {
	$output->writeln("<error>Unknown path provided: $sourcePathOption</error>");
	return 1;
	}

Any idea @nextcloud/server-triage

[MorrisJobke]

cc @nextcloud/ldap

[blizzz]

Ownership transfer hast to be done before deleting the user

[oskarb]

@blizzz

Ownership transfer hast to be done before deleting the user

That is unfortunate, and to me, quite frankly, a flawed design. There is no way in AD to technically prevent someone from deleting the account if there are files still in Nextcloud. Even if documenting procedures etc, mistakes will be made. The current handling then means that it violates design principles such as "least surprise" and "protect the user's data", if large amount of data in one system is silently lost just because a user identity was dropped in a different system.

Nextcloud would be better if it acknowledges this and the design was changed so that the files could be "resurrected" even if the current owner has been deleted from AD/LDAP.

I recognize that I don't know the internals of this or the difficulty, but from my naive viewpoint it seems like it shouldn't really be too difficult. Nextcloud does still know about the user (ldap remnants) so it seems like all the required information is still there. Alternatively, perhaps too much information is removed automatically when the user is dropped from LDAP?

It can be compared with Google's services. I think it might be an option, but at least in our environment, when an AD account is deleted, the corresponding Google account is not deleted, but just marked as suspended. No data is deleted, nor does it become impossible to retrieve.

I don't know exactly what Nextcloud does internally when a user is deleted from LDAP, but it is confusing. The user becomes invisible from the Users page in the web interface, so as admin you are unaware that it hasn't been completely deleted. occ users:list also claims the user doesn't exist, but after having found it through ldap remnants, we must then anyway use occ users:delete in order to remove it completely even though the sister command occ users:list already said it doesn't exist. I think this is inconsistent.

There is already a "disable user" button in Nextcloud. I think it would be much clearer if the LDAP integration could be made to just disable the Nextcloud user corresponding to a deleted LDAP user. This would lead to more accurate data in the Users list, and perhaps also make file transer away from that user trivial.

Future improvements aside, how can I resurrect the current data? Is there some way to create a new AD account and link it up, or otherwise tweak the nextcloud database to resurrect the user to the level required for file transfership to work?

[blizzz]

@oskarb indeed it is tied to the user deletion process, which is at the moment difficult for external user backends. So, the deleted user from LDAP is present more or less in a zombie or heisenberg mode: the user exists, yet she does not. It's something I like to tackle, but … priorities.

Future improvements aside, how can I resurrect the current data? Is there some way to create a new AD account and link it up, or otherwise tweak the nextcloud database to resurrect the user to the level required for file transfership to work?

Yes, when you ensure that the DN is going to be matching, you create a dummy user on LDAP, transfer the ownership and delete the record again. Mind the LDAP cache, you can change the configuration slightly (e.g. setting Cache TTL up or down a second) to have the cache flushed (after creating the dummy on ldap). Alternatively, manually (and temporarily) adding a record with the same user to the oc_users table might work, too, not 100% sure as of now.

[oskarb]

@blizzz Priorities are always difficult. I hope it improves eventually then.

Resurrecting the user worked but then of course I could still not access the files because someone had enable encryption on this server, the individual user had not enabled recovery key and of course we don't know the password for someone that left the company a year ago.

Now we are getting beyond the original topic, but in case it's an easy answer....

I want to get rid of the encryption. We have these commands:

encryption:decrypt-all              Disable server-side encryption and decrypt all files
encryption:disable                  Disable encryption

Documentation for "disable" just sort of states the obvious, that it disables encryption, but doesn't describe what happens to existing encrypted files. Am I to understand that they are left as is, but then decrypted user-by-user or file-by-file on demand?

Documentation for decrypt and decrypt-all does (in one location) state that this requires that each individual user must have enabled recovery keys. Clearly they haven't because no one knew to tell them this and by default it's off it seems.

Is a suitable approach to use encryption:disable to prevent new encryption, and then work with each user individually over the following days or weeks to get them to enable recovery keys and decrypt them one-by-one?

[skjnldsv]

@blizz what is the status here? :)

[RafDeCoster]

I'm having this issue as well. In my setup users are provisioned via ldap. When they leave the department they are removed from the provisioning security groups and thus nextcloud considers them not valid anymore.
At this point you would still like to transfer the files to an admin nextcloud account after which you delete the user. People coming in and out happens all the time here.

Thanks for looking into this.
Best,
Raf

[Volker-K]

We had similar problems.
Normally, a user listed in
php occ ldap:show-remnants
still exists within NC and their files can be transferred, the user then can be deleted with user:delete. files:transfer-ownership and user:delete are the only commands that work with such users.
In some cases they won't work. I could successfully transfer files and remove the user in those cases by creating a local NC user with the same ID. It's a hack that lacks beauty but it worked.

[Toraih]

Having the same problem... disabled ldap-user is blocking sync of several users ('cause of shared files).
files:transfer-ownership didn't work (ex-ldap-user to nextcloud-local-admin-user).

We can't create dummy-users on ldap, since it will start a chain of automated processes.
I moved the files by hand in the CLI and did a user:delete and files:scan afterwards (but this way the share-infos get lost and i have to share the files again).
I'll try it next time with a local dummy NC-user...

But files:transfer-ownership should be made able to handle removed ldap-users ...

Another things is, that the involved error-messages are too unclear, it took me a quite a while to figure out, that the origin of the problem comes from a another user and not the one who receives the errors.

[blizzz]

#17717 might help with that. unsure whether it is complete, and i didn't do much testing yet.

[bluikko]

This problem should actually be of critical or at least important priority.

Because (as mentioned in #15536 (comment)) NC Desktop stops working when a deleted user has shared files it means the "remnants" users must be deleted ASAP and automatically. Or perhaps the bug #11551 that causes Desktop client stop working could be fixed!

[bunjes]

This is a problem here as well.

[blizz]

I've been receiving these emails by mistake for some years (blizz vs blizzz) and now for the first time I may become a user of nextcloud as a new client of mine has it installed.  I've also been included by mistake in a discussion on another project possibly mistaken again for blizzz where the discussion is about whether to call their software open source or available source etc.  Brett On Wednesday, February 12, 2020, 3:28:16 AM MST, bunjes <[email protected]> wrote: This is a problem here as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[skjnldsv]

#17717 might help with that. unsure whether it is complete, and i didn't do much testing yet.

Anybody tried this?

[bluikko]

I gave up, wrote a cron job that deletes remnants of absent LDAP users and just put in a policy that departments are responsible for moving data/shares before kicking off deletion processes for resigned/moved employees.

[skjnldsv]

@bluikko #17717 is part of nc19, so hopefully things will improve :)

[ghost]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

[blizzz]

@bluikko #17717 is part of nc19, so hopefully things will improve :)

it's actually in 18.0.0

[ghost]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.