Removing a user account in NS8 currently leaves behind app-specific data (mail, Webtop shared resources, NethVoice/NethCTI secrets, Samba home, etc.).
- Why are we asking: when an account is deleted, its LDAP entry disappears but data in each module's storage (Dovecot mailbox, Webtop VFS documents, NethCTI secrets, Samba home directory, and so on) stays on disk indefinitely, consuming space and leaving stale/orphaned data behind.
- Purpose: give admins a way to reclaim disk space and avoid leftover data lingering after account removal, without requiring manual per-module commands.
Proposed solution
Implement an automated and scheduled procedure that periodically scans for orphaned data — i.e. data belonging to a username no longer present in LDAP — and removes it per module. Each module (mail, webtop, nethvoice, samba, nextcloud, etc.) would expose a "cleanup orphaned data" action that the scheduler calls, so the logic lives with the module that owns the data format instead of a central script guessing paths.
Alternative solutions
Add a flag (or per-service flags) at account-removal time to trigger immediate cleanup of the corresponding data, rather than a scheduled sweep. Simpler to reason about, but riskier for cases where a user should temporarily stay disabled without losing data (e.g. Webtop, see the forum thread). Also for external LDAP servers this has the same limitation of NS7.
Additional context
Manual cleanup is possible today but undocumented per-app; commands vary depending on module.
In NS7 a similar feature exists, at least with an internal LDAP account provider.
See also
Removing a user account in NS8 currently leaves behind app-specific data (mail, Webtop shared resources, NethVoice/NethCTI secrets, Samba home, etc.).
Proposed solution
Implement an automated and scheduled procedure that periodically scans for orphaned data — i.e. data belonging to a username no longer present in LDAP — and removes it per module. Each module (mail, webtop, nethvoice, samba, nextcloud, etc.) would expose a "cleanup orphaned data" action that the scheduler calls, so the logic lives with the module that owns the data format instead of a central script guessing paths.
Alternative solutions
Add a flag (or per-service flags) at account-removal time to trigger immediate cleanup of the corresponding data, rather than a scheduled sweep. Simpler to reason about, but riskier for cases where a user should temporarily stay disabled without losing data (e.g. Webtop, see the forum thread). Also for external LDAP servers this has the same limitation of NS7.
Additional context
Manual cleanup is possible today but undocumented per-app; commands vary depending on module.
In NS7 a similar feature exists, at least with an internal LDAP account provider.
See also