Nextcloud with AD backend, User deleted in AD without unsharing calendar, calendar can not be removed or unshared anymore

@mrmarkuz
@Shane_Treweek

Finally got down to this…

The wrapper works, however, as the user is deleted in AD, I just get an error message “user not found”…
The shared calendar is still there… :frowning:

Any ideas?
Thanks

Andy

can you try it ommitting everything before occ (without the sudo -u apache php)?
nevermind, I see you have figured it out. :+1:

Hi @dnutan

I did try with just occ - the command works.

I still can’t get rid of the shared calendar as the commands to show calendars by that user or to delete calendars from that user only shows “user unknown”… :frowning:

The user actually was deleted in AD, as intended. I did not expect a shared calendar to be unremoveable…

I do not have any Nextclouds on NethServer using LDAP (All my clients and I myself need AD…), but if it is replicatable in LDAP too, I think I’ve found a serious bug…

If a user is removed, the users shared calendar (and maybe other objects) should still be removeable…

:frowning:

My 2 cents
Andy

I don’t know… instead of the username can you try with the internal codename or uid, if available?
the one you get with occ user:list, if still present

Good idea… Now to see if I can extract that from a DB (It’s not shown anymore, as the user does not exist anymore…)

yep, if doesn’t show up anywhere else, it shall be in some of the tables… or even in the user folder name

Does the PHPMyAdmin module still work with the newer MariaDB / PHP used?

The user folder name isn’t available anymore. (Or maybe never existed).
AD is on a different NethServer.

I’ll probably need to recover an older version of the DB (I do have plenty of working / tested backups…)

last time I tried it didn’t work. Here in the forum there are some comments by Steph and me regarding what shall be needed to use it (specifying the new service port…)

All these workarounds needed because Centos7 has such old versions…
It’s really about time for a newer basis - the code-bloat is one of the major disadvantages of LTS systems…

do not recall if it worked or not or if @stephdl applied some fix…

1 Like

Just thinking it might be less effort to restore the AD to the date before the user was deleted, and see if I can solve the problem this way…

A backup with PBS is fast:

INFO: transferred 1.05 GiB in 4 seconds (269.0 MiB/s)

When it’s this fast, why bother with snapshots! :slight_smile:

restore image complete (bytes=107374182400, duration=24.06s, speed=4255.77MB/s)

After solving this, I can restore the current backup of AD… (If it works or not!)

Solution

Despite all occ comands, the shared calendar could NOT be removed from being displayed in other users calendars. The main problem: The user was deleted / can’t be found…

The solution which works - and also shows that a backup too many is better than one too little…

  • The environment is running on Proxmox, with backups on a PBS.
  • AD is a seperate NethServer from the Nextcloud-NethServer, making this more difficult to solve just using Nextclouds options.
  • Created a current backup of NethServer AD on PBS (To restore if successful!).
  • Shutting down the AD and restoring the version from a day before the usewr was deleted.
  • Logging into Nextcloud as that user who shared the calendar and removing the share.
  • Loging out and verifying with my own user if that users shared calendar still showed up. It didn’t!
  • Logged out of Nextcloud.
  • Shut down NethServer AD.
  • Restore the last backup from PBS.
  • Everything works!
  • User shared calendar is gone!

Success !

A few notes:

If this was a real Windows environment with a Windows AD, and a Windows member running AD, I’d probably have had to remove the Nextcloud-NethServer from AD and then reboot and re-add it to AD. Windows changes the “join” password often in the background.

With NethServer, despite the deletion being 5 weeks back, this wasn’t needed.

This was very frustrating - if I had known the solution was so easy…
It was one of the reasons I separated the AD from the rest in the first place!

:slight_smile:

My 2 cents
Andy

2 Likes

Oh no, I’m too late, it would have been much simpler:

Show deleted users (just marked as deleted)

occ ldap:show-remnants

You get a table listing the remnants:

+--------------------------------------+----------------------------------------------------+---------------+-----------------------------------------------------------+-------------------+-------------------+-----+--------+
| Nextcloud name                       | Display Name                                       | LDAP UID      | LDAP DN                                                   | Last Login        | Detected on       | Dir | Sharer |
+--------------------------------------+----------------------------------------------------+---------------+-----------------------------------------------------------+-------------------+-------------------+-----+--------+
| 2B4F13C2-7F2F-4A5C-AB58-8EFDABE4BA44 | ncuser1 (ncuser1)                                  | ncuser1       | cn=ncuser1,cn=users,dc=ad,dc=mrmarkuz,dc=test,dc=tld      | February 10, 2022 | February 10, 2022 |     | N      |

Delete User by “Nextcloud Name”:

occ user:delete 2B4F13C2-7F2F-4A5C-AB58-8EFDABE4BA44

See Nextcloud docs.

4 Likes

@mrmarkuz

Fully agree this would have been easier…

But I still consider this a NextCloud Bug - remnants should NOT be left…

If a user deletes a file, he either expects the file to be gone - or in the trashbin.
But not “frozen” in limbo…

I need to be a bit more current in occ comands… Or do I really? It should just work!

My 2 cents
Andy

2 Likes

It’s like an LDAP users trashbin.
Nextcloud has it in the documentation so I don’t think it’s a bug.
We could automate the deletion but this may not be wanted in any case :thinking:

1 Like

No but it could be a nice nfr

1 Like

May i disagree?
Nextcloud kept data as intended and programmed. It was… unpleasant due to sharing of the calendar to other users, but… if there was no calendar shared, no one cared.

Limits of integrations are… engineering connections. Sometimes the “external user related data” has to be kept, sometimes should be deleted, and it’s not NextCloud developers decide which one is the right path. Assuming that NextCloud is a database, should the records created by a user deleted after the deletion of user login data?

My suggestion here, @Andy_Wismer is to write the documentation for your system maintenance. Believe me, I’d face the same issue if i were in the same place.

Hi @pike

I still disagree.

If there’s a button in the Web-GUI of Nextcloud to “unshare” the calendar (avilable for any user who sees the shared calendar) , it should work, and not give an non-descript error message (Something like unknown error)…

This should NOT be dependant if the resource is still there or not.

Nextcloud is good, works generally very well. But…

They announce too much - and deliver less.

Your own data and privacy issues (GDPR): No way to download your data as user when no more using Nextcloud…
They at least have an App the Admin can install.
The user clicks on an App to request his data.
The admin get’s a mail saying the user requests his data…

But NO way to actually give the user his data - like most cloud solutions do offer their users in a simple way.
It’s not easy for an admin to collect files.
Calendar and Contacts are fairly trivial, but they are not the mainstay of Nextcloud, that is files…

Add to that the fact that Karlichek (The creator of Own/Nextcloud) is german, so he knows their very strict laws!

I actually have documentation of my IT environment - written all in DokuWiki, as here NethServer uses… :slight_smile:

But to document something, that something has to react correctly, predictably and same in same situations. For Nextcloud, that is not quite valid…

Even their programming terms signify this: “remnants”…

If it’s a GUI function, that GUI function should simply work!

And this is the Bug in my opinion: a non working GUI function…

My 2 cents
Andy

1 Like

Sorry, Andy…
Simple != Correct != Necessary.

Again, the offending problem was “annyoing calendar of a not working here (anymore) person”.
I can relate and understand complaining with a not working feature (unshare calendar), IMVHO in some organizations this feature should be… not available for some users and calendars, and certified, as a part of the statement “persons have access to that schedule 24/7”.

Complaining about GDPR… It’ a so bigger speech but, as a customer of “PrivateSkySpace” I would totally support the criticism.
Except that… as a workplace, any data into NextCloud is not property of the user, is property of the firm. And this should be stated as part of the contract. So the feature IMVHO should not be present.

Context and environment is a really gamechanger for these distributed service application.
As a company owner of the NextCloud installation, i would not enable “remnants delete” (Copyright Andy2Cents) as standard policy.
Starting from the IT manager.

This specific Nextcloud is not workspace data, so data are owned by users.

Same goes for my home Nextcloud. I use it, so do some friends…
GDPR is not critical for me here.

It was an error, the user (admin-cal) had a typo in the username and needed to be re-created.
The calendar was shared for testing, then the wrong username was “seen”…
It was corrected, but left testing calendars (“Official” Public holidays). To make matters worse, it was the wrong calendar…

Remnants delete has to be done as admin, so there’s no option to enable or not.

For Workspace / Companies this is a different issue, there as data is produced during paid time, the result of that work belongs to the company…

My 2 cents
Andy