Connexion Synology Drive Client via internet

[Kramlech]

Il y a 12 heures, TuringFan a dit :

accès/synchro Drive sans problème depuis mon navigateur internet et/ou mon iPhone en WAN/VPN/LAN, en revanche la synchro PC ne se fait pas en WAN.

Au final, ça marche ou ça ne marche pas en WAN ?

Tu accèdes via un NDD aussi bien en local qu'en WAN ?

Tu es certain que tu accèdes bien à ton NAS via ce NDD dans tous les cas ?

[TuringFan]

@Kramlech,

il y a une heure, Kramlech a dit :

Au final, ça marche ou ça ne marche pas en WAN ?

Tu accèdes via un NDD aussi bien en local qu'en WAN ?

J'accède en WAN/VPN/LAN à mon Drive sans problème via le client de mon iPhone (drive.ndd.tld) et/ou mon navigateur (https://drive.ndd.tld).

Via le client PC pas de problème en LAN (drive.ndd.tld ou drive.ndd.tld:6690 ou nas.ndd.tld) mais impossible en WAN.

il y a une heure, Kramlech a dit :

Tu es certain que tu accèdes bien à ton NAS via ce NDD dans tous les cas ?

Je ne suis pas certain de comprendre : j'utilise différents reverse proxy / redirection DNS registrar du type application.ndd.tld en LAN et/ou WAN pour différentes applications donc je dirais que oui.

J'espère avoir correctement répondu à ta question.

Merci de ton aide,

[.Shad.]

Ça ne peut pas marcher d'utiliser drive.ndd.tld avec le port 6690.

Si drive.ndd.tld est une entrée de proxy, il y a déjà une redirection qui se fait en arrière plan vu que ce domaine est interprété par Nginx.

drive.ndd.tld pointe vers l'interface de Drive, ça n'a strictement rien à voir avec le transit des données sur le port 6690. Tu peux comparer ça au port de l'interface de Download Station avec le port utilisé pour le protocole BitTorrent. Ce sont deux choses totalement distinctes.

Pour synchroniser depuis l'extérieur, il faut que le client Drive pointe sur l'IP publique, et que le domaine utilisé ne corresponde à aucune entrée du proxy inversé. Même chose en local d'ailleurs, sauf que domaine cible doit pointer sur ton NAS, encore une fois sans utiliser d'entrée de proxy inversé.

[TuringFan]

Merci @.Shad.,

J'ai bien essayé d'utiliser ndd.tld:6690 ou ndd.tld dans le client PC mais impossible de se connecter.

Edit : A noter que j'ai un DDNS (i) sur mon routeur dont le nom d'hote est ndd.tld et le statut est normal et (ii) un DDNS sur mon registrar dont le nom d’hôte est .ndd.tld et qui pointe bien vers mon IP externe

Ai-je fait une erreur ?

[.Shad.]

Que donnent sur ton PC :

nslookup ndd.tld

quand tu es à distance et quand tu es en local ? (tu peux simuler l'accès distant en utilisant ton smartphone en point d'accès sans fil)

[TuringFan]

@.Shad.

Commande nslookup ndd.tld

> Sortie WAN

Réponse ne faisant pas autorité :

Nom : ndd.tld

Adress : @IP externe qui correspond à celle donnée ici

> Sortie LAN

Serveur : UnKnown

Address : Ip locale de mon routeur (et non de mon NAS)

Nom : ndd.tld

 

[.Shad.]

Donc pour l'accès distant, si tu as redirigé le port 6690 de ton routeur/box vers le NAS, et que tu as autorisé dans le pare-feu du NAS les connexions distantes pour le port 6690, ça doit fonctionner.
Pour tester, tu ouvres temporairement le port 6690 au monde entier dans le pare-feu du NAS, et tu fais un test de port sur https://www.yougetsignal.com/tools/open-ports/

Pour l'accès local c'est normal que ça ne marche pas si ndd.tld pointe vers ton routeur, Drive n'est pas installé sur ce dernier. Mais j'imagine que tu veux garder le même nom de domaine cible que tu sois en local ou à distance ?

Dans ce cas-là c'est très simple. Dans ta zone OVH tu crées un CNAME du type :

synchro-drive.ndd.tld          CNAME          ndd.tld

ou si tu as un wildcard tu n'as rien à y ajouter, en tout cas tu utilises ce domaine dans Drive Client pour PC.

Dans ta zone locale, tu crées un enregistrement qui fait pointer ce même domaine vers ton NAS, si tu as déjà un enregistrement A pour ton NAS tu peux faire un CNAME :

synchro-drive.ndd.tld          CNAME          nas.ndd.tld
nas.ndd.tld                    A              IP_locale_du_NAS

Si pas d'enregistrement A préexistant pour le NAS :

synchro-drive.ndd.tld          A          IP_locale_du_NAS

Dans tous les cas, ce domaine synchro-drive.ndd.tld ne doit surtout pas correspondre à une entrée de proxy inversé !!

 

[TuringFan]

il y a 7 minutes, .Shad. a dit :

Pour tester, tu ouvres temporairement le port 6690 au monde entier dans le pare-feu du NAS, et tu fais un test de port sur https://www.yougetsignal.com/tools/open-ports/

Premier problème, le site affiche un port 6690 fermé !

Voici ma configuration de mon pare feu NAS :



Voici ma configuration transferts de port sur mon Routeur (lui même en DMZ de ma LiveBox)

Je ne vois pas ce qui cloche ?

il y a 13 minutes, .Shad. a dit :

Mais j'imagine que tu veux garder le même nom de domaine cible que tu sois en local ou à distance ?

Oui,

il y a 13 minutes, .Shad. a dit :

si tu as un wildcard tu n'as rien à y ajouter

J'ai bien un certificat wildcard; Dois avoir une entrée de type *.ndd.tld CNAME ndd.tld ?

il y a 16 minutes, .Shad. a dit :

Dans ta zone locale, tu crées un enregistrement qui fait pointer ce même domaine vers ton NAS, si tu as déjà un enregistrement A pour ton NAS tu peux faire un CNAME :

synchro-drive.ndd.tld          CNAME          nas.ndd.tld
nas.ndd.tld                    CNAME          IP_locale_du_NAS

Si pas d'enregistrement A préexistant pour le NAS :

synchro-drive.ndd.tld          A          IP_locale_du_NAS

J'ai déjà plusieurs entrée A vers le NAS : serait un problème d'en créer une de plus ?

J'ai donc créé les deux entrées CNAME.

il y a 18 minutes, .Shad. a dit :

Dans tous les cas, ce domaine synchro-drive.ndd.tld ne doit surtout pas correspondre à une entrée de proxy inversé !!

OK très clair.

---
Sans rapport avec ce fil :

Merci @.Shad. cela est peut être une piste pour un problème sur un autre sujet (que nous ne détaillerons pas ici)

il y a 19 minutes, .Shad. a dit :

Pour l'accès local c'est normal que ça ne marche pas si ndd.tld pointe vers ton routeur

@oracle7 peut être simplement un mauvais paramétrage de mon DDNS sur le problème du serveur email mentionné ici. As tu to DDNS sur ton routeur ou nas ?

Pardon @.Shad. pour l’apartée

[.Shad.]

il y a 6 minutes, TuringFan a dit :

Premier problème, le site affiche un port 6690 fermé !

Ok donc on sait déjà comment il se fait que ça ne synchronise pas à distance. 😉 Reste à trouver pourquoi.

Est-ce que tu peux mettre des images plus globales du pare-feu de ton NAS et de la table de redirection de ports de ton routeur ? Ne cache que les IP publiques éventuelles et les domaines, le reste on n'en ferait rien. 😉 

il y a 10 minutes, TuringFan a dit :

J'ai bien un certificat wildcard; Dois avoir une entrée de type *.ndd.tld CNAME ndd.tld ?

Oui si tu as déjà cette entrée c'est nickel. 👌

il y a 10 minutes, TuringFan a dit :

J'ai déjà plusieurs entrée A vers le NAS : serait un problème d'en créer une de plus ?

J'ai donc créé les deux entrées CNAME.

Coquille de ma part !! ce ne sont évidemment pas deux CNAME, mais un CNAME qui pointe lui-même vers un A, voir mon edit. Pas gênant d'en avoir un de plus, après de manière générale on évite d'avoir trop d'enregistrement A distincts, le jour où tu déplaces ton proxy inversé sur un autre NAS ou un autre périphérique, tu dois modifier individuellement chaque enregistrement, avec des CNAME tu n'as que le A en bout de chaîne à changer. 😉

Après correction de l'enregistrement pour lequel je t'ai induit en erreur, tu devrais avoir une synchronisation fonctionnelle en local, en t'assurant que le client Drive pour PC ait comme cible : synchro-drive.ndd.tld (ou quoique ce soit d'autre que tu aies choisi 🙂), et sous réserve que la configuration du pare-feu et les redirections de port sont valides.

 

[oracle7]

@TuringFan

Bonjour,

il y a 19 minutes, TuringFan a dit :

As tu to DDNS sur ton routeur ou nas ?

OUI sur les deux (RT et NAS) le DDNS pour ndd.tld pointe sur mon @IP externe

@.Shad.

il y a 45 minutes, .Shad. a dit :

Dans tous les cas, ce domaine synchro-drive.ndd.tld ne doit surtout pas correspondre à une entrée de proxy inversé !!

Je ne comprends pas ton assertion, dans mon cas (je viens de vérifier), dans mon proxy inversé j'ai une redirection du type https://drive.ndd.tld:443 --> http:localhost:10002 protégée par un profil d'accès autorisant l'accès uniquement lorsque une connexion VPN est établie à mon VPN Plus Serveur du routeur RT2600ac, et cela marche impeccable.

Dans ces conditions une connexion externe sous VPN avec un smartphone en 4G me permet d'atteindre drive sans problème avec une entrée de proxy inversé.

Dans ma zone DNS locale j'ai bien aussi :

drive.ndd.tld          CNAME          nas.ndd.tld
nas.ndd.tld              A            IP_locale_du_NAS

Cordialement

oracle7😉

[.Shad.]

Tu parles de l'interface de Drive, on parle de la synchro, ça n'a rien à voir l'un avec l'autre, voir mon message : 

C'est ce qu'a déjà dit @Kramlech sur d'autres fils de discussion également.

[TuringFan]

il y a 19 minutes, .Shad. a dit :

Est-ce que tu peux mettre des images plus globales du pare-feu de ton NAS et de la table de redirection de ports de ton routeur ? Ne cache que les IP publiques éventuelles et les domaines, le reste on n'en ferait rien.

Routeur

NAS

il y a 20 minutes, .Shad. a dit :

Oui si tu as déjà cette entrée c'est nickel.

Non je ne l'ai pas, j'avais volontairement créé une entrée par service pour avoir des redirection que dans ces cas plutot que dans une infinité de cas (chaine de caractère aléatoire puis ndd.tld) mais c'est peut être pas le plus malin ? Au besoin je peux le change, au moins ponctuellement.

il y a 23 minutes, .Shad. a dit :

mais un CNAME qui pointe lui-même vers un

C'est modifié, j'ai créé la première entrée (synchro-drive), j'avais déjà l'autre.

il y a 24 minutes, .Shad. a dit :

tu devrais avoir une synchronisation fonctionnelle en local, en t'assurant que le client Drive pour PC ait comme cible : synchro-drive.ndd.tld

Je te confirme, cela fonctionne.

Mes questionnements :

1. Reste donc à comprendre ce qui cloche en WAN ?
2. Autre question, mon DDNS pointe vers mon routeur et non mon NAS : jusqu'à présent cela n'a jamais été un problème pourtant. Ex : j'utilise notes via navigateur, client iphone ou client PC sans problème depuis l'exterieur avec note.ndd.tld.

Merci beaucoup pour ton aide,

[oracle7]

@.Shad.

Bonjour,

Effectivement, je parlais de l'interface Drive.

Pour la synchro, je n'ai rien de plus que le port 6690 ouvert dans le pare-feu du NAS et aucun soucis. Je ne vois d'ailleurs pas l'intérêt de mettre un domaine attaché à ce port. Puisque ce port ne sert qu'à des échanges "techniques" entre serveur et client si j'ai bien compris la chose, mais je peux me tromper.

Cordialement

oracle7😉

[.Shad.]

@TuringFan

Ok pour la redirection de ports sur le RT et le pare-feu du NAS.

Il y a 5 heures, TuringFan a dit :

Non je ne l'ai pas, j'avais volontairement créé une entrée par service pour avoir des redirection que dans ces cas plutot que dans une infinité de cas (chaine de caractère aléatoire puis ndd.tld) mais c'est peut être pas le plus malin ? Au besoin je peux le change, au moins ponctuellement.

Si tu fais cohabiter un wildcard et des CNAME individuels, les CNAME individuels sont prioritaires. Si par exemple ton wildcard mène vers ton IP publique, et que tu utilises le même nom de domaine pour des services sur un VPS avec des CNAME spécifiques, les enregistrements individuels prennent le pas, puis si pas d'entrée spécifique dans ta zone pour le domaine demandé, ça part vers le wildcard.

Dans ton cas, les deux pointent vers la même IP, donc pas de souci (du coup tu fais comme tu veux).

Est-ce que tu observes le même comportement pour d'autres ports ?
Au vu de la configuration que tu as, tu pourrais éventuellement rencontrer le même problème pour le port HTTPS, et les ports de MailPlus.

Qu'en est-il ?

Pour aller dans le sens de ce que suggérait @oracle7 quant au cache résiduel, tu peux tenter la même connexion depuis un onglet en navigation privée sur ton navigateur.

@oracle7

Il y a 5 heures, oracle7 a dit :

Je ne vois d'ailleurs pas l'intérêt de mettre un domaine attaché à ce port.

C'est purement didactique pour la résolution du problème, ça pourrait aussi bien être nas.ndd.tld.
Par contre ça ne pourrait pas être le domaine racine, car si j'ai bien compris il faut pointer son domaine racine ndd.tld sur le routeur.
Donc de l'extérieur, ce domaine mènerait au NAS quand on sollicite le port 6690 car il fait l'objet d'une redirection, et en local ça mènerait vers le routeur. Donc suivant si son PC se trouve en local ou à distance, utiliser le même domaine ne serait pas possible.
D'où la nécessité d'avoir un domaine autre que le racine qui, quelque soit la vue, mène au NAS.

[oracle7]

@.Shad.

Bonjour,

Merci pour ton explication, claire comme d'hab ...

Cordialement

oracle7😉

 

[TuringFan]

il y a 34 minutes, .Shad. a dit :

Si tu fais cohabiter un wildcard et des CNAME individuels, les CNAME individuels sont prioritaires. Si par exemple ton wildcard mène vers ton IP publique, et que tu utilises le même nom de domaine pour des services sur un VPS avec des CNAME spécifiques, les enregistrements individuels prennent le pas, puis si pas d'entrée spécifique dans ta zone pour le domaine demandé, ça part vers le wildcard.

Je ne suis pas certain de comprendre car je ne maitrise pas le concept de VPS.

En revanche j'avais commencé à me poser la question des redirection une par une en CNAME ou avec une redirection *.ndd.tld et je me suis dit que si demain je voulais ajouter un second NAS sur un autre réseau (pour du backup) une solution pourrait être de n'avoir sur mon registrar que des redirections unitaires CNAME et différents DDNS : (i) un DDNS sur mon NAS actuel avec le domaine ndd.tld et un DDNS sur second NAS de backup avec un nom de domaine du type backup.ndd.tld. Est-ce une bonne solution ? Cela permet il d'éviter le problème que tu mentionnais ?

il y a 41 minutes, .Shad. a dit :

Est-ce que tu observes le même comportement pour d'autres ports ?

A priori j'utilise Note Station en client PC sans problème depuis le WAN. D'une façon générale j'utilise de nombreux services depuis le WAN donc j'aurais tendance à dire que non je n'observe pas ce problème sur d'autres ports.

il y a 42 minutes, .Shad. a dit :

Au vu de la configuration que tu as, tu pourrais éventuellement rencontrer le même problème pour le port HTTPS, et les ports de MailPlus.

J'ai MPS sur mon NA et j'utilise MailPlus en client : aucun problème pour envoyer des e-mails en revanche leur réception se fait systématiquement sur le serveur OVH que je récupère ensuite sur MailPlus via du POP3, impossible de réceptionner sur MPS directement ... C'est mon autre gros problème du moment sur lequel @oracle7 m'aide. Ma configuration et mon problème sont résumés ici en quelques lignes.

il y a 46 minutes, .Shad. a dit :

Pour aller dans le sens de ce que suggérait @oracle7 quant au cache résiduel, tu peux tenter la même connexion depuis un onglet en navigation privée sur ton navigateur.

Je ne sui pas certain de comprendre : je n'ai jamais aucun problème de connexion via mon navigateur que cela soit en WAN ou en LAN. Mon seul problème est sur le client PC.

il y a 48 minutes, .Shad. a dit :

Par contre ça ne pourrait pas être le domaine racine, car si j'ai bien compris il faut pointer son domaine racine ndd.tld sur le routeur.

Oui ndd.tld pointe sur mon routeur.
Effectivement nas.ndd.tld (et donc synchro-drive.ndd.tld via l'entrée CNAME) pointe en DNS local vers l'IP locale de mon NAS.
Sur mon DNS OVH j'ai une entrée nas.ndd.tld CNAME ndd.tld : comment les paquets "savent" que je veux joindre mon NAS sur un sous réseau de mon routeur et non le routeur (ndd.tld pointe en effet vers le routeur et non le NAS) ? Est-ce le port qui est fermé sur le routeur mais transféré et/ ouvert sur le NAS ?
 

[.Shad.]

il y a 25 minutes, TuringFan a dit :

En revanche j'avais commencé à me poser la question des redirection une par une en CNAME ou avec une redirection *.ndd.tld et je me suis dit que si demain je voulais ajouter un second NAS sur un autre réseau (pour du backup) une solution pourrait être de n'avoir sur mon registrar que des redirections unitaires CNAME et différents DDNS : (i) un DDNS sur mon NAS actuel avec le domaine ndd.tld et un DDNS sur second NAS de backup avec un nom de domaine du type backup.ndd.tld. Est-ce une bonne solution ? Cela permet il d'éviter le problème que tu mentionnais ?

Ce dont je parle n'est pas un problème, juste la manière dont ça fonctionne.
Tu peux très bien utiliser 2 DDNS et rediriger les services aux bonnes adresses.

il y a 29 minutes, TuringFan a dit :

Sur mon DNS OVH j'ai une entrée nas.ndd.tld CNAME ndd.tld : comment les paquets "savent" que je veux joindre mon NAS sur un sous réseau de mon routeur et non le routeur (ndd.tld pointe en effet vers le routeur et non le NAS) ? Est-ce le port qui est fermé sur le routeur mais transféré et/ ouvert sur le NAS ?

Les paquets ne le "savent" pas, le routeur étant en DMZ sur la box, toute requête sur un port qui n'est pas redirigé en amont par la box est donc transférée sur le routeur. Si le port fait l'objet d'une redirection vers un périphérique de ton réseau, le routeur le transfère, sinon, c'est pour sa pomme.

Dans ton cas, avec une configuration identique au niveau du routeur, et du pare-feu du NAS (toutes sources autorisées), les ports HTTPS et 6690 ne se comportent pas de la même manière. Et pas seulement pour le port HTTPS, mais tous les autres ports d'après tes dires.

Et d'autre part tout a l'air de fonctionner en local, donc difficile d'incriminer le paramétrage de Drive.

Au vu des éléments donnés, je ne m'explique pas le problème.

Tu peux toujours vérifier sur quelles interfaces émet Drive, et s'il est bien en écoute, en tapant cette commande en SSH :

netstat -tulpn | grep -E '6690.*LISTEN'

 

[TuringFan]

Bonjour à tous,

Pour info j'ai fait une session AnyDesk avec le support Synology et ça n'a pas été très utile ...

A date j'ai toujours le même comportement :
- accès Drive depuis VPN/LAN OK via interface web et/ou application iPhone/iPad et/ou client PC
- accès Drive depuis WAN OK via interface web et/ou application iPhone/iPad
- accès Drive depuis WAN KO via client PC

Port 6690 ouvert sur le NAS et forwardé sur le Routeur mais tout semble exactement agir comme si ce n'était pas le cas !

J'ai aussi noté un comportement bizarre avec l'application sur l'iPhone de ma fiancée : accès sans problème en WAN mais pas possible en LAN ! Su mon iPhone aucun problème en revanche.

Je suis un peu perdu,

[TuringFan]

Le 07/02/2021 à 21:54, .Shad. a dit :

Tu peux toujours vérifier sur quelles interfaces émet Drive, et s'il est bien en écoute, en tapant cette commande en SSH :

netstat -tulpn | grep -E '6690.*LISTEN'

@.Shad.

Pardon, je me rends compte que je n'avais pas répondu à cette question, voici le résultat en ontenu en accès root sous PuTTY via le LAN :

 
 

Le 07/02/2021 à 14:00, .Shad. a dit :

fais un test de port sur https://www.yougetsignal.com/tools/open-ports/

Je peux me tromper mais après différents test j'ai l'impression que ce site affiche en ouvert les ports ouverts sur le parefeu de mon routeur mais pas ceux transférés et ouverts sur le nas mais fermés sur le routeur : est-ce normal ?

Merci d'avance si quelqu’un voit un truc,

[.Shad.]

Sur ton impression d'écran on voit bien que Drive écoute sur toutes les interfaces en IPv4 et IPv6. Donc de ce côté-là c'est ok.

Pour moi sur ton RT, un port est considéré comme fermé dès lors qu'il n'est pas transféré, ou alors il y a un onglet pare-feu propre au routeur ?

Si pas, dès lors qu'un port est transféré c'est son état sur le NAS en l'occurrence qui va être renvoyé au port checker.

Tu peux tester temporairement de mettre le NAS dans la DMZ du RT, voir si l'état des ports varie. 

[TuringFan]

il y a 3 minutes, .Shad. a dit :

Pour moi sur ton RT, un port est considéré comme fermé dès lors qu'il n'est pas transféré, ou alors il y a un onglet pare-feu propre au routeur ?

Oui, il y a deux onglets : un onglet de transfert et un onglet de pare-feu routeur. dans mon cas le port 6690 est uniquement transféré mais pas ouvert sur le routeur.
 

il y a 6 minutes, .Shad. a dit :

Tu peux tester temporairement de mettre le NAS dans la DMZ du RT, voir si l'état des ports varie.

Bingo, le site indique bien le port 6690 quand le NAS est en DMZ, fermé sinon ce qui tendrait à monter (i) que le port est bien ouvert sur le NAS et (ii) que le transfert n'est pas opérationnel.

Pour info dans mon transfert j’indique 6690 en port public et en port privé avec en destinataire l'IP locale de mon NAS. Le port 6690 est fermé sur le routeur.

Transférer un port impose t il d'également l'ouvrir sur le routeur même si aucun service ne s'en sert dessus ?

[.Shad.]

Que ce soit les règles du pare-feu ou de redirection, ça revient à faire de l'iptables.
iptables résout les requêtes qui arrivent de manière séquentielle. Les règles du pare-feu se trouvent sûrement en amont de tout le reste, de fait si un paquet est sensé être drop ou refused à ce niveau-là, le parcours des règles iptables s'arrête instantanément.
Pour que le transfert soit effectif, il me semble très logique que ce port soit a priori autorisé, puis la redirection transfère la requête au NAS. En ce sens tu n'atteindras jamais le port 6690 du routeur.

[TuringFan]

il y a 1 minute, .Shad. a dit :

Que ce soit les règles du pare-feu ou de redirection, ça revient à faire de l'iptables.
iptables résout les requêtes qui arrivent de manière séquentielle. Les règles du pare-feu se trouvent sûrement en amont de tout le reste, de faire si un paquet est sensé être drop ou refused à ce niveau-là, le parcours des règles iptables s'arrête.
Pour que le transfert soit effectif, il me semble très logique que ce port soit a priori autorisé, puis la redirection transfère la requête au NAS. En ce sens tu n'atteindras jamais le port 6690 du routeur.

OK, pas certain de bien maitriser le sujet mais je comprends que quand on veut transférer un port P au travers du routeur vers un appareil X (sur lequel P sera autorisé) il faut alors également l'ouvrir sur le routeur même si sur cette machine aucun service ne l'utilise.

C'est pas super logique pour moi mais visiblement (test du DMZ) tu as raison.

[TuringFan]

Bingo !

J'ai l'impression que ça marche !

Il semblerait que j'ai également résolu mon autre gros problème du moment (serveur mail ici) par la même occasion !

Merci @.Shad. et @oracle7 pour votre aide !

[oracle7]

@.Shad. Merci pour l'indication. Je dormirai encore moins bête ce soir ...😜

@TuringFan Merci aussi à toi d'avoir poser la question.

Du coup maintenant, je découvre un autre problème chez moi, en voulant créer une règle d'ouverture du port 6690 dans le pare-feu du RT, je constate que je ne peux pas l'enregistrer/sauvegarder. Le processus plante et SRM revient automatiquement au login avec un message comme quoi mon utilisateur administrateur n'est pas autorisé à faire cela. Un comble, non ?

Éventuellement vous avez une idée ? Je prend bien volontiers.

Cordialement

oracle7😉