Projet perso : serveur de partage de fichiers


#1

Bonjour à tous,

(j’espère poster dans la bonne catégorie)

Je souhaiterais avoir vos avis et conseils sur un projet perso : je voudrais installer sur mon réseau local un petit serveur de partage de fichiers (hébergeant principalement mes photos, epub, pdf, etc.) sur lequel se connecteront mes 2 ordinateurs : un pc sur Debian 9 (Stretch) et un MacBook sur macOS 10.14 (Mojave).

Partant du principe que j’ai déjà le serveur (i5-4430@3Ghz/16Mo/4To) et qu’il accueillera une Debian 10 (Buster), quel est le meilleur protocole à utiliser (sécurité ?) pour que mes 2 ordinateurs puissent communiquer en lecture/écriture avec le serveur : NFSv4 ou samba ? (ou autre chose ?)

J’aurais d’autres conseils à vous demander par la suite…

Par avance merci pour votre aide,
R1


#2

Bonjour,

Je ne sais pas trop quoi répondre à cela. Les deux protocoles fonctionnent avec MacOSX et aucun des deux n’est vraiment sécurisé. C’est destiné à un usage sur un réseau privé de toute façon.
J’aurais tendance à conseiller NFS qui me semble plus sûr et plus simple à configurer.


#3

Merci Bruno pour ta réponse.
Je vais donc suivre tes conseils et opter pour NFSv4.

Par contre, comment cela va se passer au niveau des permissions de fichiers : j’ai 2 utilisateurs différents (“erwan” sur Debian et “chloe” sur Mac) qui doivent accéder à certains mêmes répertoires sur ce serveur.

Je pensais mettre ces 2 utilisateurs dans un groupe particulier (disons “shares”) et à positionner les dossiers et fichiers communs respectivement en 775 et 664.
Est-ce comme cela qu’on procède ?
Ensuite, comment imposer à l’OS de tels droits lors de la création de nouveaux dossiers et fichiers ?


#4

NFS en version 4 apporte le support des ACL, c’est pas tous jeune mais te montrera quelque trucs :

https://www.osc.edu/book/export/html/4523


#5

Un peu de lecture : https://debian-handbook.info/browse/fr-FR/stable/sect.nfs-file-server.html
(voir aussi les deux premier liens donnés dans cette page).

Tu n’as pas forcément besoin des acl qui vont compliquer la configuration et diminuer les performances.

Avec NFS l’identification se fait par machine et non par utilisateur, les options permettent de faire correspondre ou non les UID et GID suivant les besoins (cf. man exports).


#6

Alors, à l’aide des liens que vous m’avez fournis (merci à tous les deux) j’ai réussi à installer mon serveur.
Concernant les accès :

  • depuis linux : accès en lecture/écriture sur les dossiers partagés. (mais erwan ne peut pas modifier un fichier crée par chloe et vis-versa, pour l’instant)
  • depuis macos : accès en lecture seulement !

Sur le serveur :

$ id erwan
uid=1000(erwan) gid=1000(erwan) groups=1000(erwan),9999(shares)
$ id chloe
uid=1001(chloe) gid=1001(chloe) groups=1001(chloe),9999(shares)

Par contre, sur le mac l’ id n’est pas le même :

$ id chloe
uid=502(chloe) gid=20(staff) groups=20(staff),9999(shares),12(everyone),61(localaccounts),399(com.apple.access_ssh),702(com.apple.sharepoint.group.2),701(com.apple.sharepoint.group.1),704(com.apple.sharepoint.group.4),100(_lpoperator),703(com.apple.sharepoint.group.3)

Est-ce que ça peut poser réellement un problème au niveau des accès ? (j’ai lu sur certains - vieux - sites qu’il fallait obligatoirement le même id)
J’aurais tendance à dire non car je n’aurais même pas accès en lecture sinon.

Voici à titre d’information le dossier partagé (qui me sert de test) sur le serveur :

erwan@debian:/export/photos$ ls -ld Catalogues\ Lightroom/
drwxrwxr-x 3 erwan shares 9 Sep 10 18:53 'Catalogues Lightroom/'

Je ne me suis pas encore lancé dans les ACL car j’ai l’impression de ne pas être très loin de la solution.


#7

Bonjour

Quels sont les attributs des fichiers créés par erwan et chloe ?

Il est possible que par défaut, pour les fichiers créés par erwan et chloe
leurs attributs concernant le groupe ne permettent que la lecture (<=> r--)


Voici, sur ma machine,
les attributs par défaut qui ont été donnés à un fichier que j’ai créé :

-rw-r--r-- 1 michel michel 4480 août  23 01:45 fich01.txt

Chacun peut modifier avec chmod les attributs des fichiers qu’il a créé
et donc, changer les attributs concernant le groupe

Par exemple,
pour permettre au groupe l’accès en écriture au fichier nommé nomDuFichier :

chmod g+w nomDuFichier

#8

Il faut surtout nous montrer ton fichier /etc/exports


#9

Oui c’est effectivement les attributs créés par défaut qui ne sont pas bons (mais je ne sais pas comment imposer un 664 au lieu de 644 et l’appartenance au groupe “shares” à chaque création)

$ ll
total 67
drwxrwxr-x  2 erwan  shares   5 Sep 10 21:34 ./
drwxrwxr-x 24 root   shares  37 Aug 30 17:27 ../
-rw-r--r--  1 chloe  chloe    5 Sep 10 18:53 tata
-rw-r--r--  1 erwan  erwan    5 Sep  9 12:47 titi
-rw-r--r--  1 chloe  chloe    5 Sep  9 12:48 tutu

Sinon :

$ cat /etc/exports
/export		192.168.1.0/24(ro,sync,root_squash,no_subtree_check,fsid=0)
/export/photos	192.168.1.0/24(rw,sync,root_squash,no_subtree_check)

#10

Bonjour,

Ce lien peut-il t’aider ?


#11

Merci Albert pour ton lien mais je me suis mal exprimé, désolé : en fait je sais gérer les droits via umask. (ça fonctionne d’ailleurs correctement en local sur le serveur avec un umask égale à 002)
Ce que je voulais dire c’est que je ne sais pas quelle config faire pour que ça fonctionne via mon montage NFS et que je ne connais aucune commande qui permet d’imposer un groupe particulier lors de la création d’un fichier/répertoire via NFS.

Sinon en faisant mes tests, je me suis aperçu d’un autre problème sur ma config: mon montage par systemd ne fonctionne pas du tout en version 4 mais en version 3 :

# cat /etc/systemd/system/mnt-photos.mount 
[Unit]
  Description=NFS Photos mount
  Requires=network-online.target
  After=network-online.service
[Mount]
  What=192.168.1.254:/export/photos
  Where=/mnt/photos
  Type=nfs
  Options=_netdev,auto,nfsvers=4
[Install]
  WantedBy=multi-user.target
# mount
[...]
192.168.1.254:/export/photos on /mnt/photos type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.254,mountvers=3,mountport=53305,mountproto=udp,local_lock=none,addr=192.168.1.254,_netdev)

J’ai essayé aussi avec l’option vers=4 mais elle ne semble pas être prise en compte elle aussi.

Alors que via la commande mount, ça fonctionne bien en version 4 :

# mount -t nfs4 192.168.1.254:/photos /mnt/photos
# mount
[...]
192.168.1.254:/photos on /mnt/photos type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.21,local_lock=none,addr=192.168.1.254)

Et sachant ça, j’ai refais mes tests de lecture/écriture en NFSv4 : les fichiers nouvellement créés sont en 666 et les dossiers en 777, c’est à dire que l’umask n’est plus du tout appliqué ! (ni celui du serveur 002, ni ceux des 2 ordinateurs 0022)


#12

Un fichier appartiennent à l’utilisateur qui le crée et à son groupe principal. Les droits d’accès sont définis par la variable UMASK sur le système.

Avec nfs, le serveur va utiliser l’UID et le GID de l’utilisateur qui s’est connecté ce qui risque de poser des problèmes puisque ils ne sont pas forcément les mêmes sur le serveur et les clients.
Pour éviter cela il faut utiliser l’option all_squash qui va faire correspondre n’importe quel UID/GID envoyé par un client à nobody/nogroup. (cf man exports)

/export/photos	192.168.1.0/24(rw,sync,all_squash,no_subtree_check)

#13

L’option all_squash ne résout malheureusement pas mon pb et l’empire au contraire : aucun des 2 utilisateurs (erwan & chloe) ne peux modifier quoi que ce soit via NFS maintenant, même ses propres fichiers/dossiers et le montage du lecteur réseau sur le mac est devenu impossible.

Sur le serveur :

$ cat /etc/exports
/export		192.168.1.0/24(ro,sync,all_squash,no_subtree_check,fsid=0)
/export/photos	192.168.1.0/24(rw,sync,all_squash,no_subtree_check)

puis depuis le pc debian :

$ id
uid=1000(erwan) gid=1000(erwan) groups=1000(erwan),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),114(scanner),9999(shares)
erwan@debian:/mnt/photos/Catalogues Lightroom$ ll
total 93
drwxrwxr-x  4 erwan  shares  10 Sep 11 17:11 ./
drwxrwxr-x 24 root   shares  37 Aug 30 17:27 ../
-rw-r--r--  1 chloe  chloe    5 Sep 10 18:53 tata
-rw-rw-rw-  1 chloe  chloe    0 Sep 11 00:58 test
drwxrwxrwx  2 chloe  chloe    2 Sep 11 01:03 test2/
drwxrwxr-x  2 erwan  erwan    2 Sep 11 01:04 test3/
-rw-rw-rw-  1 erwan  erwan   10 Sep 11 00:01 tete
-rw-r--r--  1 erwan  erwan    5 Sep  9 12:47 titi
-rw-rw-r--  1 erwan  erwan    5 Sep 10 23:04 toto
-rw-r--r--  1 chloe  chloe    5 Sep  9 12:48 tutu
erwan@debian:/mnt/photos/Catalogues Lightroom$ 
erwan@debian:/mnt/photos/Catalogues Lightroom$ rm tete
rm: cannot remove 'tete': Permission denied
erwan@debian:/mnt/photos/Catalogues Lightroom$

Par acquis de conscience, à chaque modif de config je redémarre carrément le serveur pour être sûr + démontage/montage ensuite du dossier partagé (via systemd puis tests avec mount) depuis le pc Debian.


#14

Je n’ai pas détaillé l’explication en pensant que tu lirais la page de man pour voir si cela te convenait ou pas.
SI tu utilises l’option all_squash il faut que tous les fichiers et dossier contenus dans le dossier partagé appartiennent à nobody:nogroup
Si tu ne l’utilises pas les fichiers créés par erwan auront l’UID 1000 et le gid 1000, ceux créés par chloe auront l’UID 502 et le GID 20.