Plus d'accès smb depuis mise à jour vers Truenas 12U1

[captainkuru]

Bonjour à tous,

j'espère que quelqu’un à la solution à mon problème parce que je commence à m'arracher les cheveux.

J'utilise Freenas depuis la version 8 sans le moindre soucis.
J'ai 4 volumes que je partageais simplement via 4 lignes dans "partage SMB", sans dataset particuliers.
J'y accédais sous le compte root (NAS à la maison, pas de connexion vers l'extérieur, pas la peine de chercher la complication).
J'ai eu plusieurs config, toutes en AMD, pour finir avec ma config actuelle, carte mère Supermicro h8scm-f, Opteron 4365EE (8 coeurs, 2,0ghz), 40go de RAM REG ECC.
Et j'ai aussi un autre NAS sous Freenas 11 pour sauvegarder par Rsync.

J'ai connu Freenas 9, 11 et Truenas 12 en RC, aucun problème. Puis j'ai fais la mise à jour vers Truenas 12U1 et là catastrophe, tout fonctionne bien mais je n'ai plus accès à mes partages.
Le compte root est refusé dans l'explorer windows (10 64bits version 2004), ok je crée donc un compte Tom, ça passe dans l'explorer et je vois bien mes 4 volumes :
- le premier, j'ai un contrôle total
- le deuxième je peux que lire (windows me dit que je n'ai pas les privilèges pour y faire plus)
- les 3e et 4e, accès refusé

J'ai tout bidouillé pendant des heures, création de dataset + ACL et compagnie, fonctionnalités de Windows 10 activation de SMB1, ça change rien de rien.
J'ai essayé de revenir à des versions précédentes mais ça marche pas non plus, en 12RC j'ai les mêmes problèmes d'accès alors qu'avant la mise à jour j'étais en 12RC et tout roulait avec le compte root. J'ai lu des dizaines de forums sans arriver à grand chose. Je pige pas pourquoi j'ai accès à un volume, à moitié à un autre et pas du tout au reste... Si l'un d'entre vous à connu la même chose...

 

[Heracles]

Bonjour,

La description que tu donnes pointe directement sur les ACLs. La gestion des ACLs a changé dans TrueNAS 12. Ainsi, il faudrait que tu nous donnes les chemins d'accès vers chacun de tes répertoires partagés, le propriétaire de chacun de ces répertoires et les permissions appliquées dessus. La commande ls -alF /mnt/poolname/dataset/directory donnera les infos requises. Bien entendu, ajuste le chemin d'accès à ta situation...

 

[captainkuru]

Bonjour et merci pour ta réponse,

pour mieux comprendre j'ai 4 volumes que je partage sans dataset qui correspondent à des disques physiques :

Octo 2x2 To en raid 1
Kitsune 2x4 To en raid 1
Sherpa 2x2 To en raid 1
Iou 1x320 Go seul

Je précise que pour avoir accès à plus de fichiers j'ai tapé un coup de

setfacl -m everyone@:rxaRc::allow /mnt/nom des volumes

Mais celà ne m'avance pas beaucoup plus.




Voici les résultats que tu as demandé :

Warning: settings changed through the CLI are not written to
the configuration database and will be reset on reboot.



root@Truenas-13[~]# ls -alF /mnt/Octo
total 59
drwxr-xr-x+ 7 root wheel 7 Dec 30 13:40 ./
drwxr-xr-x 6 root wheel 320 Jan 7 15:09 ../
drwxr-xr-x 10 root wheel 10 Dec 27 10:52 .system/
drwxr-xr-x 2 root wheel 112 Jul 6 2020 Anafi/
drwx------ 3 root wheel 3 Jan 26 2019 Huawei/
drwxrwxrwx 54 root wheel 54 Jan 7 14:28 Photos/
drwxr-xr-x 3 root wheel 65 Jul 6 2020 Video/



root@Truenas-13[~]# ls -alF /mnt/Kitsune
total 9
drwxr-xr-x+ 3 root wheel 3 Dec 31 11:36 ./
drwxr-xr-x 6 root wheel 320 Jan 7 15:09 ../
drwxr-xr-x 9 root wheel 9 Oct 6 10:33 Japon/



root@Truenas-13[~]# ls -alF /mnt/Sherpa
total 6896
drwxr-xr-x+ 13 root wheel 25 Jan 2 11:17 ./
drwxr-xr-x 6 root wheel 320 Jan 7 15:09 ../
-rwx------ 1 root wheel 306287 Jul 21 2013 75539.jpg*
drwx------ 2 root wheel 3 Feb 9 2017 à graver/
-rwx------ 1 root wheel 812361 Nov 26 2013 autumn_in_japan_by_seeyouspacecowboy14-d4lc6j9.jpg*
drwx------ 13 root wheel 34 Dec 22 20:29 Docs/
-rwx------ 1 root wheel 453019 Nov 26 2013 Dusk_in_Tokyo__Japan_by_KintaiZach.jpg*
-rwx------ 1 root wheel 777585 Aug 4 2013 escalator_by_burningmonk-d5topd0.jpg*
-rwx------ 1 root wheel 1012459 Aug 4 2013 f_u_j_i_by_burningmonk-d3fyiro.jpg*
drwx------ 19 root wheel 129 Nov 8 10:24 Films/
-rwx------ 1 root wheel 1112066 Aug 4 2013 g_l_a_s_s_e_s_by_burningmonk-d57fyng.jpg*
-rwx------ 1 root wheel 208514 Dec 21 2012 gravity-rush-for-vita-releasedate.jpg*
-rwx------ 1 root wheel 1846184 Aug 4 2013 h_o_k_o_k_u_j_i_by_burningmonk-d3llwk2.jpg*
drwx------ 38 root wheel 54 Nov 26 09:59 Jeux/
-rw-r--r-- 1 root wheel 35 Sep 1 13:54 Mise à jour Freenas-10.txt
drwx------ 2 root wheel 3 Nov 7 2017 Mounette/
drwx------ 52 root wheel 87 Oct 8 11:21 Musique/
drwx------ 5 root wheel 10 Feb 10 2017 SAUV DM1/
drwx------ 5 root wheel 5 Sep 1 13:54 SAUV FREEBOX/
drwx------ 3 root wheel 15 Feb 10 2017 SAUV OPTERON/
drwxrwxrwx+ 2 root wheel 2 Jan 2 11:16 SherpaWindows/
drwx------ 70 root wheel 100 Oct 10 12:02 SUITE/
-rw-r--r-- 1 root wheel 0 Oct 1 18:19 Test 01 10 2020.txt
-rwx------ 1 root wheel 110592 May 13 2018 Thumbs.db*
-rwx------ 1 root wheel 336084 Aug 4 2013 Tokyo.jpg*



root@Truenas-13[~]# ls -alF /mnt/Iou
total 274
drwxr-xr-x+ 18 Tom mounette 21 Dec 26 13:27 ./
drwxr-xr-x 6 root wheel 320 Jan 7 15:09 ../
drwxrwxrwx 7 Tom mounette 11 Dec 24 13:18 Antoine/
drwxrwxrwx 6 root mounette 13 Oct 30 2019 Construction et travaux maison/
drwxrwxrwx 9 Tom mounette 11 Oct 17 2019 Cours exposés et rapportsde stage/
-rw-rw-rw- 1 Tom mounette 13577 Nov 18 2019 Dépenses voyage Japon 2019.xlsx
drwxrwxrwx 8 root mounette 8 Dec 29 16:48 Disquettes/
drwxrwxrwx 3 Tom mounette 13 Oct 30 2019 Factures/
drwxrwxrwx 4 Tom mounette 5 Oct 30 2019 Impôts/
drwxr-xr-x 4 root mounette 4 Sep 7 18:54 Japon/
drwxrwxrwx 4 Tom mounette 6 Sep 3 2019 JCS1 Japonais debutant Module 1/
drwxrwxrwx 3 Tom mounette 6 Apr 13 2020 Mots de passe/
drwxrwxr-x 2 mounette mounette 9 Oct 3 11:09 mounette/
drwxrwx--- 2 mounette Mounette 10 Apr 15 2020 Mounette/
drwxrwxrwx 2 Tom mounette 6 Apr 13 2020 Mouni/
drwxrwxrwx 19 Tom mounette 20 Oct 30 2019 Musique/
drwxrwxrwx 29 Tom mounette 48 Aug 18 16:11 Photos/
drwxrwxrwx 2 Tom mounette 3 Apr 13 2020 Santé/
-rw-r--r-- 1 root mounette 0 Sep 30 17:53 Test 30 09 2020.txt
-rw-rw-rw- 1 root mounette 21504 Jul 17 2016 Thumbs.db
drwxrwxrwx 3 Tom mounette 11 Dec 30 13:38 Travail/

Les permissions sont très hétérogènes, ce qui est étrange parce que j'ai toujours tout fait à partir du compte root finalement... C'est quand même con qu'on ne puisse plus se connecter aux partage SMB avec le compte root.

 

[captainkuru]

Je viens de désactiver le service SMB, supprimer les 4 partages SMB, mis mon utilisateur dans le groupe Wheel uniquement, recréé les partages et là surprise des étiquettes ACL bleues apparaissent maintenat à côté des mnt\nom des volumes. Je n'avais pas ça avant.

Cela dit je suis quand même toujours bloqué dans mes permissions.

 

[Heracles]

C'est quand même con qu'on ne puisse plus se connecter aux partage SMB avec le compte root.

En vérité, ce qui est con est de l'avoir fait pendant tout ce temps... Le compte Root est le compte associé aux droits du système. Il n'y a besoin d'aucun privilège système pour accéder des fichiers de données. Ainsi, que ce compte soit interdit d'accès vers Samba, c'est plus que compréhensible.

En exemple, même dans SSH ont interdit souvent le compte Root. La raison est que son usage masque l'identité de celui qui se connecte. Ainsi, même si SSH a pour but de manipuler le système et de faire usage des droits système, ont l'interdit à Root.

Donc pour en revenir à ta situation :
--Il est préférable de travailler à une solution qui n'utilisera plus le root. Ce sera plus sécuritaire et plus évolutif.
--Cela implique que plusieurs permissions devront être modifiées dans ta configuration actuelle.
--Il est plus simple de reprendre du début que de jouer aux devinettes

Ainsi, je t'invite à procéder comme suit :
--créer un nouveau dataset
--Donner la propriété de ce nouveau dataset à ton compte utilisateur et à un groupe utilisateur (pas "wheel")
--Va dans la ligne de commande et vérifie que la propriété, le groupe et les permissions sont bien ce que tu voulais
--Crée ensuite un nouveau partage SMB
--Tente d'utiliser ce nouveau partage depuis ton Windows

Une fois que tu auras réussi cela, on pourra regarder pour le rétablissement de l'accès vers tes autres données. Ou bien en ajustant les données et configurations là où elles sont, ou bien en déplaçant les données vers de nouveaux partages comme celui-ci.

Bonne chance

 

[captainkuru]

Salut,

rassure toi, je suis bien conscient qu'utiliser le compte root n'est pas du tout sécuritaire, seulement mon Nas date de freenas 8 et il était facile de mettre un coup de root dans Windows et c'était torché. Je suis le seul à utiliser le Nas, il n'est pas connecté à l'extérieur, j'ai un pare-feu matériel ultra agressif sur mon réseau, les risques étaient limités...

Je n'ai aucun soucis pour créer des nouveaux dataset avec ACL et les partager, j'ai bien un accès total à ces dataset mais ils sont vide et je n'ai plus accès aux donnés des disques qui étaient sagement stockée sur la racine de mes disques. Comment ça se passe pour les "rapatrier" dans les nouveaux dataset? Parce que là à par remplir les nouveaux dataset à partir de mon Nas de sauvegarde je peut rien faire d'autre.

 

[captainkuru]

Mon problème est résolu !

Depuis la dernière mise à jour j'ai pu reprendre la main sur mes volumes via la console, ce que Truenas me refusait avant. Je peux donc maintenant accéder sans restrictions à mes volumes directement, sans créer d'autres couples dataset utilisateurs-ACL, directement depuis le dataset racine du volume.

Avant mes volumes appartenaient à root, mais plus possible d'accéder aux volumes par SMB en se connectant via root depuis Truenas, j'ai donc créé un nouvel utilisateur. Donc il a fallut changer le propriétaire des volumes et indiquer le niveau des autorisations pour chacun.

J'ai simplement utilisé les commandes suivantes :

Connaître propriétaire volume :
getfacl /mnt/nom de volume

Changer propriétaire volume :
chown -R nom du nouveau proprio /mnt/nom du volume
chown -R nom du nouveau groupe /mnt/nom du volume

Changer niveau autorisation :
chmod -R 755 /mnt/nom du volume (! 755 ou autre selon vos besoins, voir tableau valeurs octales https://fr.wikipedia.org/wiki/Chmod)