- État En cours de résolution
- Pourcentage achevé
- Type Anomalie
- Catégorie Services locaux → SMB
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 4.8.18
- Due pour la version Non décidée
-
Échéance
Non décidée
-
Votes
1
- Shade69 (11/02/2025)
- Privée
Ouverte par Shade69 - 11/02/2025
Dernière modification par mmakassikis - 17/03/2025
FS#40051 - Samba : Partage SMB en R/W non-fonctionnel pour iOS depuis l'app Fichier (ReadOnly depuis iOS18)
Bonjour à toute l’équipe Freebox,
Je souhaitais vous faire un retour un “bug” qui ne vient pas forcément de la Freebox mais de comment iOS à apparement changer sa méthode de connexion côté client sur le serveur SMB.
[Problème rencontré :]
En effet, depuis iOS18, on ne peut se connecter aujourd’hui qu’en lecture seule (R) et non lecture-écriture (RW) depuis iOS et l’application native, Fichier (File).
Ce problème n’existe pas sur la pile SMB de macOS Séquoia (15.3.1) et est apparu depuis la première version d’iOS18. Il n’y avait aucun soucis sur iOS17 avec l’application Fichier.
Je l’ai remonté en fin d’année 2024 sur https:// https://www.apple.com/feedback/, sans succès depuis, sachant que de leur point de vue ce n’est peut-être pas un problème mais une mesure de sécurité supplémentaire ?
Dans l’application Fichier, vous pouvez ajouter que ce soit en local (xxx.freeboxos.fr) ou en distant (WireGuard), l’accès au disque dur de la Freebox c’est qui est très pratique en tant que NAS à part entière.
[Solution :]
Source : https://discussions.apple.com/thread/255775451
Ajouter cette ligne dans la configuration de Samba de la Freebox.
vfs objects = streams_xattr
La directive vfs objects = streams_xattr dans le fichier de configuration de Samba (smb.conf) permet d’activer un module VFS (Virtual File System) qui gère les flux alternatifs de données (ADS - Alternate Data Streams) via les attributs étendus (xattr).
Explication technique
1. SMB et les flux alternatifs
• SMB prend en charge les flux alternatifs, ce qui signifie qu’un fichier peut contenir des métadonnées ou des informations supplémentaires qui ne sont pas directement visibles dans le fichier principal.
2. streams_xattr et les attributs étendus
• Sur un serveur Samba, les systèmes de fichiers comme ext4, XFS ou Btrfs ne gèrent pas naturellement les flux alternatifs comme NTFS. • streams_xattr simule cette fonctionnalité en stockant ces flux dans des attributs étendus (xattr). • Sans cette configuration, certains clients SMB (notamment ceux d’Apple) peuvent rencontrer des problèmes lorsqu’ils tentent d’écrire ou de modifier des fichiers.
Pourquoi macOS Finder fonctionne et pas l’app Fichiers d’iOS ?
1. La différence vient de la manière dont macOS et iOS accèdent aux partages SMB :
• macOS Finder utilise une implémentation SMB plus avancée • Finder gère mieux la négociation des capacités SMB. • Il prend en charge une rétrocompatibilité avec différentes versions de SMB. • Il semble ignorer l’absence de streams_xattr ou utiliser un autre mécanisme pour gérer les métadonnées.
2. L’app Fichiers d’iOS est plus restrictive
• Depuis iOS 18, Apple semble imposer des exigences plus strictes pour les flux alternatifs. • Si streams_xattr n’est pas activé, iOS peut restreindre l’accès en lecture seule pour éviter toute corruption des métadonnées. • Apple peut avoir renforcé la sécurité et les permissions, empêchant l’écriture si certaines extensions ne sont pas disponibles côté serveur.
Conclusion
• Sur un serveur SMB, ajouter vfs objects = streams_xattr permet à iOS de retrouver l’accès en écriture en gérant les flux alternatifs correctement. • macOS Finder semble contourner le problème via un mécanisme différent ou une tolérance plus élevée aux différences entre serveurs SMB. • Apple a peut-être mis en place un changement de protocole SMB dans iOS 18 qui impose des vérifications plus strictes des attributs de fichiers.
Il faudrait donc, je suppose, faire des tests pour voir si cela n’occasionne pas d’effets de bord sur des configurations classiques. Est-ce vous souhaiteriez l’ajouter par défaut dans la configuration SMB sans action de l’utilisateur ou ajouter une case à cocher si cela fonctionne sans régression notable dans Freebox OS / Partages de fichiers / Partage Windows / ajouter une case en-dessous de SMB2/SMB3, “Ajouter la compatibilité avec iOS” ?
Merci beaucoup pour votre aide et la mise en place de ce correctif,
Jean-Philippe
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Pourquoi ne pas simplement utiliser l'application freebox Files qui peut se plugger à l'application Fichiers sur iOS et vous permet ainsi d'accéder facilement en lecture/écriture à vos fichiers présents sur la freebox ?
Merci, Loggoi, pour la solution de contournement avec le plugin de Freebox Files. Cependant, je viens de tester, cela ne fonctionne qu'en local. En distant avec WireGuard cela ne fonctionne pas.
Pour autant, je pense que d'une ce n'est pas un comportement souhaité mais une anomalie qui peut-être réglée avec une configuration de Samba.
Tout le monde n'est pas obligé d'installer l'application pour avoir le R/W. Sachant que ça fonctionnait très bien à posteriori jusqu'a iOS17.
Merci pour le rapport de bug très détaillé. Le comportement du client SMB d'iOS est surprenant mais ce n'est pas le sujet (pas de stream_xattr ⇒ pas de métadonnées à lire/écrire, donc je ne vois pas où la corruption de données peut avoir lieu).
Il ne me reste plus qu'à trouver un client iOS 18 pour tester.
Files devrait fonctionner en local / à distance / en VPN.
Bonjour, pour information la Freebox n'utilise pas Samba mais ksmbdtools en version 3.4.6 (pas d'autres informations depuis la version FreeboxOS 4.8.9). Il y a donc utilisation de KSMBD - SMB3 Kernel Server.
La bonne nouvelle c'est que cette fonction (vfs objects = streams_xattr) semble supportée. L'idéal serait la mise à jour de ksmbdtools en 3.5.3 et ksmbd en 3.5.0 (corrections de memory leak, sécurité…) et surtout les Durable handles v1/v2.
La librairie glib semble être en 2.78 et ksmbdtools requiert >2.44
Cela semble donc possible hormis un souci côté kernel (dépendances) @mmakassikis ?
Cordialement
la version de ksmbd est à jour pour ce qui est des correctifs de sécurité/memory leak, …
les durable handles v1 peuvent avoir un intérêt. pour les v2, c'est à priori utilisé dans le contexte de cluster de serveur de fichiers donc pas d'intérêt sur une freebox.
comme dit dans mon post précédent: je préfère reproduire et voir que ça corrige effectivement le problème plutot que d'activer une fonction à l'aveugle
Merci @mmakassikis pour votre réponse, sans le plugin ça fonctionnait très bien en local/distant sur iOS17 en R/W. Maintenant seulement en Read. Avec le plugin en local et avec WireGuard (distant), j'ai testé en créant un dossier dans le plugin, celui-ci ne se reflète pas dans le partage SMB (depuis macOS)..
Pour reproduire le scénario, après la l'ajout de votre serveur SMB (smb://xxx.freeboxos.fr) dans iOS18 et l'application Fichier (File), le serveur s'affiche et en bas c'est marqué 1 élément (Lecture seule) qui dans mon cas le dossier "Freebox Ultra".
Bien à vous,
Jean-Philippe
Je pensais au V1 effectivement.
Je comprends bien et suis entièrement d'accord (env. de production, ce n'est pas un homelab).
Ce sont juste des propositions qui seraient pratiques d'avoir.
Concernant Freebox Files, je confirme que cela contourne le problème et l'accès Local, Distant et VPN et fonctionnel (iOS 18.3.1 / iPadOS 18.3.1).
Cordialement,
Bonsoir @mmakassikis,
Avez-vous pu reproduire le problème et voir si ce petit correctif fonctionne avec iOS sans créer de régression pour les autres systèmes d'exploitation desktop/mobile (Mac, Windows, Android..) ? :)
Merci beaucoup,
Jean-Philippe
bonjour Jean-Philippe,
rajouter
ne suffit pas à priori.
si le comportement est effectivement celui souhaité par Apple et ce n'est pas juste un bug, c'est … curieux.
L'application File essaie de stocker un attribut étendu 'com.apple.FinderInfo'. Les usages habituels sont:
* icônes/placement personalisés
* visibilité de fichiers dans Finder
* attributs plus spécifiques selon le type de fichier (pour un usage dans Finder)
Tous les systèmes de fichier ne permettent pas de stocker des attributs (exFAT par exemple). Dans ce cas, le comportement semble complètement erratique:
- copier un fichier fonctionne
- renommer le fichier ne fonctionne pas
- renommer un répertoire existant fonctionne (!)
- copier un fichier déjà sur le partage vers un autre répertoire ne fonctionne pas (de la pire manière possible: le fichier est copié dans son intégralité et c'est à la toute fin que ça plante)
- déplacer le fichier fonctionne (j'imagine que comme il existe déjà, File ne touche pas aux attributs ?)
Je vais retester pour vérifier que ce n'est pas un bug côté serveur qui provoque ça, mais il est possible que même en activant streams_xattr l'expérience utilisateur soit nulle depuis File/iOS. Je ne sais pas non plus ce qu'il en est avec ext4/xfs (où les attributs étendus sont supportés).
Je ne connais pas l'écosystème Apple, mais il n'est pas impossible qu'une application tierce soit meilleure concernant l'accès aux partages SMB.
Bonjour @mmakassikis, je te remercie pour ton retour rapide ! :)
Ce qui est vraiment étrange, c'est que ce comportement ne se reflète pas sur macOS alors que les systèmes sont de plus en plus proche "logiciellement parlant" d'année en année..! Également par exemple, j'utilise Infuse sur iOS/macOS et la suppression d'un fichier vidéo dans le partage SMB fonctionne, par exemple.
Merci d'avoir testé, je vais creuser de mon côté aussi en attendant, en espérant que tu trouves une solution ! ;)
Jean-Philippe
Bonjour @mmakassikis,
J'ai trouvé d'autres informations pour vous pour la configuration de Samba (ajouté en Août 2024 au Wiki) :
https://https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X
Apparement, c'est vraiment cette configuration spéciale TimeMachine qui corrigerait le problème pour macOS/iOS :
qui résoudrait les problèmes de ReadOnly aussi pour les appareils iOS comme confirmé ici (en GUI)
https://https://forum.rockstor.com/t/configure-samba-to-work-better-with-apple-devices/8956
En 2e solution, si cela ne fonctionne toujours pas et également sur sources croisées, il faudrait rajouter
sur la configuration smb du dossier partagé :
https://https://www.macobserver.com/tips/how-to/files-folders-smb-server-ios-18/ https://https://www.reddit.com/r/ios/comments/1hoyqw9/smb_read_only/
Merci beaucoup,
Jean-Philippe
j'ai oublié de mettre à jour le ticket.
j'ai refait des tests et iOS File devrait fonctionner avec les systèmes de fichier qui savent gérer des attributs étendus à partir du prochain firmware. Autrement ça sera en lecture seul. A moins d'utiliser une application tierce où il n'y a pas de problème (Owlfiles d'après le thread reddit).
Je persiste à croire que cette décision de la part d'Apple n'a aucun sens (si c'est bien une décision et pas un bug).
Merci pour le suivi, c'est une super nouvelle ! :)