CoolRaoul

Non mes options me semblent correctes (NB: peut-être que je ne comprends pas bien) une fois la restauration effectuée tout redevient normal. C'est *avant* de restaurer que le problème se manifeste (forcément!)

Pourquoi ? la restauration fonctionne (heureusement) Dans les versions récentes d'Android les restrictions accès aux fichiers sont de plus en plus strictes Pour faire court, une appli n'a accès qu'a ses propres fichiers. Par défaut (saufs droits spécifiques), pour qu'une autre appli accède à un fichier appartement à appli tierce elle doit obligatoirement passer par les fonction du "Storage Access Framework". Pas de open(), read(), write() etc ... Seuls les fichiers de certains dossiers (Download par exemple) sont accessibles sans restrictions. =========================== NB: je ne reçois toujours pas les notifications de réponse alors que je suis abonné au fil. C'est ennuyeux. C'est toujours pas résolu ce problème ? Moi non plus (après restauration de ceux à problème). Sur un très grand nombre de fichiers pdf je n'ai été confronté à ce dysfonctionnement que sur 2 ou 3 en plusieurs mois dont juste 2 récemment.

Vérifié et restaurés oui Seuls 2 fichiers ont été touchés jusqu'ici (et j'en ai des tas de .pdf) le seul client que j'utilise pour accéder à ces fichiers là c'est Synology Drive pour Android. Et le cloisonnement des acces fichiers d'Android ne permet pas à une autre app de les modifier directement. Je soupçonne un bug tordu dans Drive (coté client ou serveur)

L'un des deux est un reçu fiscal fourni par une asso. La seule métadonnée qu'il contienne est "outil de conversionOPDF : PyPDF2" L'autre est le résultat d'un scan effectué par une appli Microsoft (je ne sais pas si on peut parler ici de "fichier Office")

Et encore nouveau .pdf vidé ce matin. Restauré avec HyperBackup aussi

Salut à tous Il vient de m'arriver pour la 2eme fois une mésaventure inquiétante : des fichiers .pdf se retrouvent subitement avec une taille vide (0 bytes) A noter que juste la taille change, pas la date : La première fois c'était lors d'un accès smartphone via Synology Drive. Erreur soudaine à l'ouverture d'un fichier auquel j'accède régulièrement. Après analyse : fichier vide. Cette fois je m'en suis aperçu en ouverture par le réseau local en SMB. Dans les deux cas HyperBackup m'a sauvé mais ce n'est pas rassurant. A noter qu'aucune erreur ne s'est manifestée dans les logs ou dans les rapports hebdos programmés que m'envoie mon NAS. Je n'ai aucune piste. Peut-être que quelqu'un a une idée ? J'ai vérifié en ligne de commande si d'autres fichiers pouvaient avoir été touchés : find . -name '*.pdf' -size 0 -ls") Apparemment tout va bien (ouf)

Ah oui en effet, ça aurait été une bonne idée de prévenir, j'ai dû utiliser "mot de passe oublié" pour retrouver l'acces au forum!

Vérifier si restart auto est activé dans le panneau de configuration DSM

Il y aurait plutot un risque que certaines de celles affichées ci-dessus ne soient pas implémentées si on se base sur cette discussion : https://www.nas-forum.com/forum/topic/75618-comment-émettre-un-wake-on-lan/?do=findComment&comment=1319479975 Mais la doc officielle de "synouser" est ici dans le CLI Administrator Guide for Synology NAS

Il existe une commande en ligne, "synouser", avec une option "--add" : $ sudo synouser Copyright (c) 2003-2022 Synology Inc. All rights reserved. Usage: synouser --help --rebuild {all|(domain Force{0|1})|(ldap Force{0|1})} --enum {local|domain|ldap|all|domain_used} --enumpre {local|domain|all|domain_used} prefix Caseless{0|1} --enumsub {local|domain|all|domain_used} substr Caseless{0|1} --enum_admin {local|domain|ldap|all} --get username --getuid UID --add [username pwd "full name" expired{0|1} mail privilege] --modify username "full name" expired{0|1} mail --rename old_username new_username --setpw username newpasswd --del username1 username2 ... --login username pwd --dbopen2 username --filesetpw --create_homes {domain|ldap} Mais l'invoquer à partir d'un formulaire web, comme c'est root (donc sudo) obligatoire, c'est quand même un peu touchy

Je suis vraiment désolé que ça soit tombé sur toi, mais je ne compte plus le nombre de fois où je tombe sur une réponse "chez moi ça marche" dans un fil ou un utilisateur vient demander de l'aide. Et parfois je réponds avec ce genre de remarque qui, je le reconnais, peut s'avérer désagréable. mieux alors: sudo tcpdump -Anq -i any 'udp port (0 or 7 or 9)' (au cas ou le nom des interface LAN est différent selon le modèle de NAS)

<HS> le fait qu'une *même* commande se comporte différemment selon qu'on utilise un chemin absolu ou la résolution via le PATH (étant donné que l'identité du chemin de la cible est confirmé par un "which <commande>" ) remet en cause toute mon expérience du fonctionnement des shells Unix. Un pointeur vers un cas avéré m'intéresse au plus haut point </HS>

Je ne suis plus chez moi la et donc plus d'accès à mon PC et à son Wireshark Mais je ne vois pas quelle différence ça pourrait faire

Voulant en avoir le cœur net j'ai testé avec Wireshark. Avec le module Python je capture bien le "magic packet": Avec "synonet --wake" : rien J'ai meme essayé un tcpdump en ligne de commande sur une autre fenêtre shell directement sur le NAS ("sudo tcpdump -i eth0 '(udp and port 7) or (udp and port 9)'") ; pas mieux

Je ne pense pas que [mention=76055]PierU[/mention] trouve utile de savoir que la méthode qu'il essaie sans succès d'utiliser marche chez d'autres. De mon côté j'ai également retesté "synonet" en ligne de commande, autant avec sudo à partir d'un compte non root que sans dans un shell "full root" ("sudo -i") et ça n'a marché dans aucun des cas.