Freebox Server (Pop V8/ Delta V7 / Revolution V6 / Server Mini 4K)

  • État Nouveau
  • Type de tâche Anomalie
  • Catégorie Non trié
  • Assignée à Personne
  • Système d'exploitation Tous
  • Sévérité Basse
  • Priorité Normale
  • Basée sur la version 4.3.4
  • Due pour la version Non décidé
  • Date d'échéance Non décidé
  • Votes 0
  • Privée Non

FS#35103 - Accès au disque dur bloqué en écriture subitement

Bonjour,

J’ai un petit souci d’intégrité de disque sur mon NAS externe alors je me suis lancé dans une recopie de certains fichiers sensibles sur le disque dur de ma Delta.
Au début aucun souci, plus de 200Go transférés puis tout à coup blocage alors que je ne suis qu’à 24% du disque.
Via le partage, je vois mes fichiers, je peux les lire mais je ne peux plus rien écrire.
“Accès au dossier de destination refusé” Vous devez disposer d’une autorisation pour effectuer cette action.

J’ai tenté quelques manips vues sur internet de
-redémarrage fbx
-arrêt partage puis activation partage
-décocher SMBv2 recocher
-définir un user
mais rien n’y fait via le partage windows

Par contre, je peux toujours uploader via l’interface web par contre mais pas vraiment pratique de passer uniquement par là.

Configuration
-Delta avec un disque acheté chez free de 1To
-connexion filaire RJ45 entre mon PC et la delta

Cette tache ne dépend pas d'autre tache

Marios Makassikis (mmakassikis)
lundi 28 juin, 2021 06:05:55

Bonjour,

Pouvez-vous m’indiquer l’adresse MAC de votre box ?

yoyo173fr (yoyo173fr)
jeudi 1 juillet, 2021 08:20:31

Bonjour,
En fait la dernière version 4.4.0 a corrigé le problème, je peux à nouveau écrire sur le disque via le partage windows

Merci pour le fix

D.-C.M. (Freemagician)
vendredi 2 juillet, 2021 21:18:07

Il peut arriver que SMB plante suite à une surcharge réseau, ou à l’envoi de données corrompues, et se place en lecture seule.
Ca arrive rarement, mais ça m’est déjà arrivé sachant que je suis en SMB1, pas en SMB2

Dans ce cas un reboot rétablit tout.

Donc votre problème peut éventuellement être lié à la nouvelle implémentation du SMB2 corrigé avec le dernier firmmare 4.4.0, ou ça peut très bien n’avoir absolument aucun lien, dans ce cas votre système remarche uniquement parce que la mise à jour du firmware implique un reboot

- je déconseille le Wifi lorsque l’on effectue des opérations d’écritures délicates et importantes sur le serveur SAMBA, le câble ethernet est beaucoup plus stable et implique beaucoup moins de paquets corrompus. L’instabilité naturelle du Wifi a tendance à parfois générer des paquets mal formés qui font planter le serveur distant. C’est un phénomène rare, mais ce phénomène existe.

- j’ai tendance à avoir ce problème, même câblé, lorsque j’effectue une sauvegarde de mes systèmes avec des outils tels que Macrium, Acronis... avec sauvegarde distante sur le serveur samba.
Le PC envoie dans ce cas de gros paquets de données de façon continue et parfois le serveur SMB subit un micro freeze à la suite duquel il se verrouille en lecture seul et fait donc planter l’opération de sauvegarde. Là encore c’est un phénomène rare, mais qui existe bien.

D.-C.M. (Freemagician)
vendredi 2 juillet, 2021 21:57:30

J’ajouterais qu’en mode câblé le scénario typique où ça peut arriver :

- un PC A connecté en cablé sur lequel est lancé une opération de sauvegarde image (Macrium, Acronis...) et qu’on ne touche pas.
- Un PC B connecté en Wifi ou lui aussi câblé qui simultanément accède à internet. On fait mumuse avec Youtube par exemple, on change de videos.... et pan la sauvegarde du PC A plante de façon aléatoire.

J’ai remarqué que les serveurs Freebox, que ce soit Delta ou Revolution, saturent assez facilement.
Lorsque deux PC ou plus se connecte sur Internet, ça ne pose pas vraiment souci... les erreurs sont en général invisible par ce que les paquets viciés sont supprimés et le navigateur fait auotmatiquement une nouvelle requête en tâche de fond pour récupérer ces données...

ça pose vraiment souci uniquement sur un PC de type A qui effectue des transferts de données massifs en continue... dans ce cas le systèmes est sensible au moindre paquet malformé
Bref, quand je sauvegarde un PC, je suis obligé d’éviter de faire autre chose

C’est encore pire si le PC A effectue une sauvegarde en tâche de fond et en même temps l’opérateur se sert de ce même PC pour naviguer sur internet, là c’est plantage garanti de la sauvegarde et éventuellement du serveur SMB dans les 10 minutes qui suivent. Tout plantage de sauvegarde n’implique pas obligatoirement celui du serveur.

Il y a peut-être éventuellement des paramétrages à revoir au niveau du parefeu Freebox.
Ca pourrait être éventuellement lié à la problématique des paquets fragmentés.

Les scénarii que je décris sont peut-être des situations qui générèrent énormément de paquets fragmentés.

Il y a dans les parefeu Linux\BSD différentes stratégies pour traiter ces paquets fragmentés afin d’établir la manière de reconstituer ces paquets.

L’une des stratégies appliquée par les paranoiaques, c’est de demander au pare feu d’abandonner les paquets fragmentés, donc de ne jamais faire de reconstitution, car en effet un paquet fragmenté peut parfois être synonyme de tentative d’attaque, ces paquets étant généré arificiellement par l’attaquant. Cette solution radicale pose en pratique énormément de problème.
Ca fout le bordel sur les jeux en ligne qui se coupent subitement, ça pose problème en réseau interne ou ça induit de nombreuses erreurs de lecture ou écriture sur un serveur NFS ou SMB

Il y a des niveau de tolérances qui se règlent. Par exemple lorsque le système reçoit un paquet fragmenté, il le met en attente le temps de recevoir les paquets manquants, ce qui du coup peut mettre en attente le transfert vu que les données doivent être reçu dans un certain ordre, sauf que si au bout de “t” secondes le système ne reçoit toujours pas le ou les paquets complémentaires, le parefeu abandonne définitivement le paquet fragmenté placé en attente avec parfois des conséquences pour les systèmes connectés.

Peut-être, si ce n’est déjà fait, faudrait-il prévoir une meilleure tolérance en augmentant sensiblement le délai “t”....

Chargement...