Gérer le nombre de comptes de manière responsable

Bonsoir,
nouveau membre via mon asso, je vois que la page la page Framaspace mentionne 50 comptes associés à un espace (en plus de 40 Go).
Merci d’abord, pour cette mise à disposition, qui me semble très utile pour aider les asso à disposer d"outils libres et qui respectent la vie privée. :slight_smile:

Ça semble pour l’instant amplement suffisant pour nos besoins, mais conscient qu’une asso vit et ses membres arrivent et repartent, je me demande donc si lorsque des membres repartent en particulier, leurs comptes peuvent être détruits sans risques pour diminuer le nombre de comptes associés à l’espace d’une asso, sans détruire les contenus qui auront été créés par ces comptes.

Il me semble que ce n’est pas problématique pour nextcloud, mais une confirmation clarifiera les choses et pourra aussi aider les nouvelles et nouveaux venus.

Je me permet de pinger @pyg (qui pourra rediriger sur quelqu’un d’autre plus pertinent)

Tu fais bien de relancer :slight_smile:

J’avais creusé la question, mais la réponse est en fait complexe.

Il y a 5 cas possibles lorsqu’un utilisateur est supprimé : What happens to your data when a user account is deleted? - Nextcloud

Traduction Deepl (non vérifiée) :


En principe, les comptes d’utilisateurs peuvent être soit désactivés, soit complètement supprimés. « Désactivé » signifie que cette personne ne peut plus se connecter, mais que les fichiers créés sont toujours disponibles - même pour les personnes avec lesquelles quelque chose a été partagé ou créé ensemble.

Les comptes d’utilisateurs peuvent être soit désactivés, soit complètement supprimés.

La question de savoir si les données sont toujours disponibles pour les membres de l’équipe lorsqu’un compte est complètement supprimé dépend de l’emplacement de stockage.

  • Cas 1 : les fichiers créés par l’utilisateur lui-même sont supprimés avec le compte d’utilisateur.
  • Cas 2 : les fichiers créés par l’utilisateur qui ont été partagés avec d’autres utilisateurs ne sont plus disponibles pour ces derniers lorsque le compte est supprimé.
  • Cas 3 : Fichiers créés par l’utilisateur, partagés avec d’autres utilisateurs et déjà modifiés par ces derniers : l’utilisateur qui a créé le fichier est également propriétaire des données - et donc ces fichiers, y compris toutes les modifications, sont supprimés lorsque le compte de l’utilisateur d’origine est supprimé.
  • Cas 4 : Fichiers créés par l’utilisateur, mais stockés dans un dossier créé par un autre utilisateur et partagé avec d’autres : dans ce cas, c’est l’origine du dossier qui détermine ce qui se passe - si quelqu’un d’autre l’a créé (et l’a partagé avec le compte à supprimer), les fichiers sont conservés.
  • Cas 5 : Fichiers créés par l’utilisateur, stockés dans un dossier de groupe : un dossier de groupe a été créé par quelqu’un d’autre (l’administrateur du système) et, par conséquent, les fichiers créés dans ce dossier sont conservés jusqu’à ce qu’ils soient explicitement supprimés, indépendamment des personnes qui les ont créés ou modifiés.

Ce que je pourrais résumer en gros, en « Si Bob a créé un fichier, il y a de très fortes chances que la suppression du compte de Bob supprime le fichier »

Je peux proposer 3 solutions, mais les trois ont l’inconvénient de perdre les partages :

Solution 1

Disons que Bob quitte l’asso et que Alice, elle, reste.

  1. Alice créé un dossier « Archives Bob », partagé avec Bob
  2. Bob COPIE ses fichiers dans le dossier « Archives Bob » (qui appartient à Alice)
  3. Alice peut supprimer l’utilisateur Bob
  4. Alice peut redispactcher les fichiers et refaire les partages

A l’étape 2, il est crucial qu’il s’agisse bien d’une copie et non d’un déplacement, car si un des fichiers de Bob avait été créé/partagé par lui, alors il ne sera pas déplacé (pour conserver le partage)

Solution 2

  • Bob partage ses dossiers avec Alice
  • Alice télécharge le dossier en local
  • Alice supprime Bob
  • Alice réuploade les fichiers de Bob
  • Alice refait les partages :confused:

Solution 3

Si Bob n’avait pas beaucoup de dossiers/fichiers, tu peux les transférer à un autre propriétaire. Tu ne peux pas transférer TOUS les fichiers d’un coup, c’est au mieux dossier racine par dossier racine.
Cf la doc ici : Transfer Ownership — Nextcloud latest User Manual latest documentation

Donc :

  1. Bob va dans ses Paramètres, puis Partages, puis Transférer la propriété
  2. Bob choisi les dossiers ou fichiers qu’il veut transférer à Alice et valide
  3. Alice reçoit une notification de transfert, qu’elle doit accepter
  4. Alice et Bob doivent patienter que le transfert ait lieu (ça peut prendre 10 ou 30mn)
  5. Alice trouvera, à la racine de son espace, des dossiers « Transferred from Bob » avec la date
  6. Le compte de Bob peut-être supprimé

Mon souci avec cette solution 3, c’est que mes tests ont montré que les fichiers partagés n’étaient pas transférés non plus :frowning:

Rappel quelque soit la solution

Bob peut toujours savoir quels sont ses fichiers/dossiers partagés en cliquant, dans l’app « Fichier » sur « Partages » dans la colonne de gauche

1 « J'aime »

Bref, tu soulève une vraie problématique, et je pense qu’il faut qu’on en discute en interne.

  • est-ce qu’on laisse les utilisateurs se débrouiller avec ces solutions ?
  • est-ce qu’on met en place le plugin Impersonate - Apps - App Store - Nextcloud ce qui signifie que l’admin de l’espace peut avoir accès à tous les fichiers ?
  • est-ce qu’on exclue les comptes désactivés de la limite des 50 comptes max ? (si Bob part, l’admin désactive son compte, mais ses fichiers/partages restent là, et Bob ne compte plus dans la limite des 50 comptes (= il compte pour zéro))
  • autre solution ?

:thinking:

1 « J'aime »

Merci bien pour ces pointeurs. :slight_smile:

Si on part de l’usage prévu, celui d’un espace collaboratif pour un collectif, alors les fichiers créés sont utiles à la structure (je ne suis pas censé déposer la vidéo du mariage de mes potes sur l’espace collectif sans aucun lien avec elles et eux), ce serait donc à elle de décider de les supprimer ou pas.
Le cas 5 serait donc le plus adapté de ce point de vue.
La solution du module Impersonate serait alors une solution adaptée.
L’exclusion des compte désactivés peut aussi fonctionner, elle semble compatible avec la philosophie de moyens raisonnables et limités accordés à chaque asso : 40Go partagés entre 50 comptes actifs et 50 inactifs, ça fait toujours 40Go, et je suppose que ça ne fait pas grande différence.

Tout à fait.

Pour le module Impersonate, j’ai (à chaud) le même avis que toi : Framaspace est fait pour héberger les données d’une asso, et donc ne devrait héberger aucune donnée « privée ».

Cependant, comme tout changement dans la sécurité, cela mérite d’être réfléchi. Par exemple, il faut que chaque utilisateurice ait conscience du fait que les admins peuvent regarder leurs fichiers.

Sinon, oui : un compte désactivé ne prend pas de ressources, donc on peut aussi envisager ça (là encore, apres réflexion et étude approfondie)

Bonsoir,

Voici un sujet délicat auquel je me suis confronté récemment, et je me suis posé les questions que vous prévoyiez alors de discuter en interne. Y aurait-il du nouveau?

Sources de données à envisager:

  • Fichiers partagés
  • Fichiers du dossier personnel non partagés
  • Données d’applications (Calendrier, etc.) partagées
  • Données d’applications non partagées

C’est cruel sans mode d’emploi précis pour chacune des sources données évoquées ci-dessus! Car depuis le compte admin, il n’est à ma connaissance pas possible de voir la liste ou au moins le nombre de fichiers de l’utilisateur. Et aucune indication pendant le transfert non plus. Donc il n’y a aucun moyen de controler ce qui est fait…

Ce serait sans doute pratique, même si cela peut aussi être gênant sur le principe. Ce qui se joue je crois c’est est-ce qu’un admin peut accéder à un compte utilisateur sans prévenir l’utilisateur auparavant (à moins que Impersonate le signale à l’utilisateur?), ce qui peut amener à des débordements.
Car un admin peut de toutes les façons accéder au compte d’un utilisateur: en modifiant l’email associée au compte, puis en procédant à la remise à zéro du mot de passe. Mais l’utilisateur le saura. Par contre ce processus est plus lourd, surtout s’il faut vérifier plusieurs comptes.

Ce serait certainement le plus simple et le plus sûr concernant les données: que la limite des comptes portent sur 50 comptes actifs et 50go de données cumulées.
Néanmoins je ne sais pas si cela est conforme par rapport au RGPD, et cela peut d’autre part grignoter progressivement le quota d’espace disque pour rien si les comptes désactivés héberges des fichiers personnels inutiles pour l’asso.

Mon retour d’expérience

Dans le cas que j’ai rencontré, je savais que l’essentiel des données étaient dans le dossier partagé. En regardant en tant qu’admin la page « Comptes », je voyais que l’espace utilisé par cet utilisateur était de 2,8mb, donc pas beaucoup de fichiers a priori.
Je suppose que ce chiffre n’inclut pas les données d’applications.

Je voulais absolument éviter de supprimer des fichiers partagés mais créés par cet utilisateur en supprimant le compte (ce type de problème: Suppression de contenu suite à la suppression d'un utilisateur)

J’ai suivi la procédure de remise à zéro du mot de passe pour me connecter au compte en question et avoir une idée des fichiers qui y étaient présents. Ensuite j’ai regardé l’activité du compte dans la page Activité afin de répérer un fichier créé par ce compte pouvant servir comme témoin

Donc j’ai procédé au transfert du dossier utilisateur entier. Un message dit que cela peut prendre une heure sans en dire plus. J’imaginais que cela concernait les comptes avec beaucoup de données, mais ici rien ne s’affichait dans l’explorateur de fichiers du compte admin vers lequel les données étaient transférées et je me demandais si le transfert avait bien fonctionné. J’ai répété l’opération plusieurs fois, et cela a fini par fonctionner au bout de 10mn (je suppose que l’info sur délai me concernait également finalement), puis quelques messages m’indiquant un échec de transfert (je suppose que le premier transfert a fonctionné, et que les messages d’échec correspondent au tentatives suivantes, quand les fichiers étaient déjà en cours de transfert).
Un dossier « Transfert depuis le compte X le j/m/a … » est apparu dans les fichiers du compte admin contenant tous dossiers/fichiers du compte X sauf le dossier partagé. En allant dans le dossier partagé, pour le fichier témoin que j’avais repéré, le propriétaire est bien le compte admin (mais comme je n’avais pas vérifié le propriétaire avant le transfert, du coup je manque d’un élément pour dire si le transfert de propriété de fichier partagé fonctionne comme prévu).

Dans tout ça je ne sais pas si les fichiers d’applications ont bien été transférés, mais dans ce cas-ci ce n’est pas bien grave.

EDIT: J’ai fait un second test avec un autre compte à transférer en prenant trois fichiers témoins:

  • 1 fichier créé depuis ce compte dans le « dossier partagé » (le propriétaire est l’admin!)
  • 1 fichier non partagé (le propriétaire est ce compte)
  • 1 fichier partagé avec un seul autre utilisateur (le propriétaire est ce compte)

Après transfert du compte en qeustion vers le compte admin, j’ai bien:

  • le fichier dans le dossier partagé qui n’a pas bougé
  • un dossier « transfert » dans le compte admin avec:
    • le fichier non partagé (le nouveau propriétaire est l’admin)
    • le fichier partagé avec une personne (le nouveau propriétaire est l’admin) et le partage avec l’autre utilisateur est toujours actif.