[RÉSOLU (partiellement)] Rsync sur partage NFS4 chown error

[juice]

Bonjour à tous.

Depuis que je suis passé à NFS v4 sur mon NAS (synology ds 209) je n’arrive plus à forcer les droits lors de l’exécution de la commande rsync qui réalise mon backup.

Code : Tout sélectionner

rsync: chown "…" failed: Invalid argument (22)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1052)

les UID/GID sont identiques entre le client et le serveur pour les utilateurs concernés par la sauvegarde.

j’ai modifié les options suivantes dans mon /etc/conf.d/nfs-common.conf comme préconisé sur https://wiki.archlinux.org/index.php/NFS :

Code : Tout sélectionner

NEED_STATD="no"
NEED_IDMAPD="yes"

le /etc/exports du serveur (seul fichier de conf présent):

Code : Tout sélectionner

/volume1        192.168.1.100/25(fsid=0,rw,sync,no_wdelay,no_root_squash)

et enfin la ligne de commande rsync :

Code : Tout sélectionner

rsync -avz --delete --ignore-errors --force --exclude-from '/etc/rsync-exclude.conf' /home /mnt/nevarsin/data/backups/$HOSTNAME/

J’ai pas mal écumé le net et je sèche…

Un rsync via ssh avec échange de clé serait-il plus approprié ?

[le Manchot Masqué]

Dans un des posts avec une erreur similaire sur la même version de NFS, le gars explique que l'erreur est due à un daemon idmap qui en marche pas, et que pour l'activer correctement, il faut également exécuter nfsd côté client ! Ça me surprend un peu, parce que ça voudrait dire que les démons communiquent entre eux, mais bon, ça ne coûte rien d'essayer...

[juice]

Il m’a effectivement semblé avoir vu quelque part qu’il falait aussi activer le daemon idmap sur le serveur. Le hic c’est que je n’ai rien trouvé en rapport à ça sur mon @$#!8X de nas. Ça a beau être du gnu/linux inside c’est pas comme une distro standard… À voir si je ne devrais pas utiliser une version ipkg de nfs-utils au lieu de celle fourni par le constructeur…

[juice]

Je me réponds à moi même… J'ai « zieuté » les logs du kernel sur le serveur et je suis effectivement tombé là dessus :

nfsd: nfsv4 idmapping failing: has idmapd not been started?

J'ai donc contourné le problème en passant le rsync avec ssh et échange de clé. Pour ceux que ça intéresse, voici la procédure que j'ai suivi :

1. Configuration et activation ssh sur le serveur

Modifier le fichier /etc/ssh/sshd_config

Code : Tout sélectionner

PermitRootLogin yes
PasswordAuthentication yes
ChallengeResponseAuthentication no

Redémarrer le service sshd (ici /usr/syno/etc/rc.d/S95sshd.sh restart)

2. Création de la clé root sur les clients

Création de la clé : ssh-keygen -b 4096 -C "$(whoami)@$(hostname)-$(date -I)"
Ajouter la clé dans le .ssh/authorized_keys du serveur avec la commande : ssh-copy-id -i /root/.ssh/id_rsa.pub root@nevarsin
Remettre l'option PasswordAuthentication à no une fois le transfert de la clé effectué pour chaque clients.

Redémarrer le service sshd.

3. Configuration de la commande rsync

Code : Tout sélectionner

DEST_DIR=nevarsin:/volume1/backup/$HOSTNAME/
LOGFILE=/var/log/backup.log

rsync -e ssh -avz --delete --ignore-errors --force --exclude-from '/etc/rsync-exclude.conf' /home $DEST_DIR 2>&1 >> $LOGFILE

Avec le script de backup placé dans un /etc/cron.daily ou weekly des clients vous avez une sauvegarde automatisée qui marche au poil.