Distribution EOLE

Les sous-dossiers sont visibles à la deuxième connexion (connexions comptées globalement : ils sont visibles après redémarrage de la machine).

Ne semble pas directement lié à https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1572132 (mais ça y ressemblait curieusement).

Avec trois dossiers, le premier montage ne montre aucun d’eux (le bug précédent correspondait au masquage des deux premiers dossiers seulement).

Dernières observations :
1. en prenant deux postes équivalents, joints au domaine (ubuntu 24.04)
2. un élève se connectant pour la première fois (après un délai indéterminé) ne voit pas les sous-dossiers
3. le même élève se reconnectant peu après voit les sous-dossiers
3bis. un autre élève appartenant au même groupe se connectant après l’autre voit les sous-dossiers
4. une connexion depuis un autre poste permet également d’accéder aux sous-dossiers.
5. après redémarrage du serveur, on peut observer le besoin de se reconnexion (les sous-dossiers n’apparaissent pas la première fois) mais ce n’est pas systématique, pas pour tous les utilisateurs (facteur de différenciation inconnu pour l’instant).

Les deux utilisateurs ont le shell linux activé dans leur profil.

Résultat d’un autre protocole visant à tester l’hypothèse suivante :
- est-ce que les sous-dossiers ne sont indisponibles que pendant un certain laps de temps ?
- est-ce que les sous-dossiers finissent par être disponibles sans avoir à reconnecter l’utilisateur ?

Après redémarrage du serveur Scribe (puisqu’il semble que ce soit une condition suffisante pour que certains utilisateurs ne voient pas les sous-dossiers à leur première connexion), boucle sur la tentative de lister le contenu de l’un des sous-dossiers. La date de début de procédure est notée dans un fichier. La date de fin de procédure est notée dans le même fichier une fois que le contenu du sous-dossier est accessible.

Les dates suivantes ont été récoltées :

lun. 26 mai 2025 16:08:21 CEST
mar. 27 mai 2025 02:05:38 CEST

Sans généraliser ce résultat, on peut observer que les sous-dossiers finissent pas être accessibles. On peut également observer que le temps avant que cela n’arrive peut être beaucoup trop long pour considérer que l’attente est un moyen adéquat de régler le problème.

Samba journalise la connexion pour la même heure :

mai 27 02:05:38 scribe smbd_audit[64846]: 2025/05/27 02:05:38|DOMPEDAGO/eleve.csq|scribe|eleve.csq|10.1.2.54|connect|ok|eleve.csq
mai 27 02:05:38 scribe smbd_audit[64846]: 2025/05/27 02:05:38|DOMPEDAGO/eleve.csq|scribe|eleve.csq|10.1.2.54|connect|ok|IPC$

Il ne semble pas y avoir d’événements liés avant cette connexion.

Autre hypothèse : problème d’authentification kerberos.

En supprimant l’option de montage sec=krb, le problème d’accès n’est plus rencontré.
La bonne gestion de l’authentification kerberos reste à trouver.

juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=scribe.dompedago.etb1.lan;ip4=10.1.3.5;sec=krb5;uid=0x8a17fae;creduid=0x8a17fae;user=eleve.test;pid=0x434a2
juin 02 08:38:28 pc-1503866 cifs.upcall[277991]: ver=2
juin 02 08:38:28 pc-1503866 cifs.upcall[277991]: host=scribe.dompedago.etb1.lan
juin 02 08:38:28 pc-1503866 cifs.upcall[277991]: ip=10.1.3.5
juin 02 08:38:28 pc-1503866 cifs.upcall[277991]: sec=1
juin 02 08:38:28 pc-1503866 cifs.upcall[277991]: uid=144801710
juin 02 08:38:28 pc-1503866 cifs.upcall[277991]: creduid=144801710
juin 02 08:38:28 pc-1503866 cifs.upcall[277991]: user=eleve.test
juin 02 08:38:28 pc-1503866 cifs.upcall[277991]: pid=275618
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: get_cachename_from_process_env: pathname=/proc/275618/environ
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_144801710
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: get_tgt_time: unable to get principal
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: krb5_get_init_creds_keytab: -1765328174
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: handle_krb5_mech: getting service ticket for scribe.dompedago.etb1.lan
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: handle_krb5_mech: using GSS-API
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: GSS-API error init_sec_context: No credentials were supplied, or the credentials were unavailable or inaccessible
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: GSS-API error init_sec_context: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_144801710)
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: handle_krb5_mech: failed to obtain service ticket via GSS (458752)
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: Unable to obtain service ticket
juin 02 08:38:28 pc-1503866 cifs.upcall[277990]: Exit status 458752
juin 02 08:38:28 pc-1503866 kernel: CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
juin 02 08:38:28 pc-1503866 kernel: CIFS: VFS: \\scribe.dompedago.etb1.lan Send error in SessSetup = -126