Table of Contents

Synology DS415+

Le DS415+ est un NAS orienté TPE/PME (malgré la garantie de seulement 2 ans !). C'est un upgrade de son grand frère le DS412+, doté de plus de mémoire et d'un processeur plus puissant (atom 4 cœurs 2.4 Ghz) qui permet le chiffrement matériel.

Packaging

Acheté le 10/10/2014 à ~490 euros.
Livré avec son transfo, 2 câbles réseaux et son OS DSM 5.0

Caractéristiques techniques

CPU : Atom Quad-Core C2538(4C/4T) @2.4 GHz (Avoton 64-bits/gravure 22nm/2MB cache/TDP 15W/VT-x et EPT/AES-NI pour le chiffrement matériel AES 256 bits)
Mémoire : 2 GB DDR3 (extensible à 8 GB officieusement et en perdant la garantie)

Emplacements : 4x baies 3.5" hot-swappable ; max 24 TB (4 disques de 6 TB, connexion interne SATA II), tiroirs screwless (sans vis)
Type de RAID : JBOD, RAID {0, 1, 5, 6, 10, SHR (Synology Hybrid RAID)}
Stockage : ext4 pour les disques internes, ext3-4, FAT, NTFS ou HFS+ pour les disques externes
Ventilation : 2x 92 mm en extraction
Bruit : 20.2 dB(A)
Alimentation : 100 W
Consommation : 46.2W (Access), 17.3W (HDD Hibernation)

Taille (hauteur-largeur-profondeur) : 165 x 203 x 233.2 mm
Poids : 2,05 kg
Garantie : 2 ans

Connectique :
   2x Gigabit (compatible link aggregation), WoL
   1x USB2 (façade), 2x USB 3
   1x eSATA

Installation

Le NAS, qui doit être connecté sur le même réseau que votre ordinateur, est détecté automatiquement et vous présente l'assistant d'installation. Ce dernier vous demande le mot de passe admin, et vous propose de télécharger seul la dernière version de DSM. 10 minutes après, DSM est lancé et accessible via votre navigateur. La durée de construction du raid (4x 4 To WD red, en une grappe de SHR (Synology Hybrid RAID)) est d'environ 1j, 5h : 

ds415> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdd5[3] sdc5[2] sdb5[1] sda5[0]
      11706850944 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      [==================>..]  resync = 93.7% (3657132392/3902283648) finish=145.4min speed=28092K/sec

Compter ensuite la durée d'installation et de configuration des différents modules (centre de paquets) et services (création des utilisateurs, partages, notifications, …), puis de migration des données et vous avez un NAS pleinement fonctionnel.

Pros & cons

+ excellentes performances mono-tâche, les meilleures pour des données chiffrées
+ petite taille (mais costaud.. )
+ bon rapport qualité/prix
+ insertion des disques simples
+ l'OS DSM bien fini et extensible via les extensions

- il arrive que les disques fassent vibrer le boitier, ce qui génère du bruit
- performances multi-tâches limitées

Sécurisation du NAS

Cette partie traite de la sécurisation (hardening) d'un NAS Synology. Parce qu'il arrive qu'il contienne des données sensibles et qu'il soit connecté à Internet, il faut prendre quelques précautions.

Sources:

système

réseau

utilisateur

alertes

MIBs/OIDs

Voici un aide-mémoire des OIDs intéressants à pooler en SNMP pour métrologiser le NAS. 

// synoSystem
systemStatus		.1.3.6.1.4.1.6574.1.1.0 = INTEGER: 1
 -> Normal(1), Failed(2)
systemTemperature	.1.3.6.1.4.1.6574.1.2.0 = INTEGER: 32
powerStatus		.1.3.6.1.4.1.6574.1.3.0 = INTEGER: 1
systemFanStatus		.1.3.6.1.4.1.6574.1.4.1.0 = INTEGER: 1
cpuFanStatus		.1.3.6.1.4.1.6574.1.4.2.0 = INTEGER: 1
modelName		.1.3.6.1.4.1.6574.1.5.1.0 = STRING: "DS415+"
serialNumber		.1.3.6.1.4.1.6574.1.5.2.0 = STRING: "xxxxxxxxxx"
version			.1.3.6.1.4.1.6574.1.5.3.0 = STRING: "DSM 5.1-5022"
upgradeAvailable	.1.3.6.1.4.1.6574.1.5.4.0 = INTEGER: 2
 -> Available(1), Unavailable(2), Connecting(3), Disconnected(4), Others(5)

// synoDisk
diskIndex		.1.3.6.1.4.1.6574.2.1.1.2.0 = STRING: "Disk 1"
diskID			?
diskModel		.1.3.6.1.4.1.6574.2.1.1.3.0 = STRING: "WD40EFRX-68WT0N0        "
diskType		.1.3.6.1.4.1.6574.2.1.1.4.0 = STRING: "SATA"
diskStatus		.1.3.6.1.4.1.6574.2.1.1.5.0 = INTEGER: 1
 -> Normal(1), Initialized(2), NotInitialized(3), SystemPartitionFailed(4), Crashed(5)
diskTemperature		.1.3.6.1.4.1.6574.2.1.1.6.0 = INTEGER: 29

// synoRaid
raidIndex		?
raidName		.1.3.6.1.4.1.6574.3.1.1.2.0 = STRING: "Volume 1"
raidStatus		.1.3.6.1.4.1.6574.3.1.1.3.0 = INTEGER: 1
 -> Normal(1), Repairing(2), Migrating(3), Expanding(4), Deleting(5), Creating(6), RaidSyncing(7),
    RaidParityChecking(8), RaidAssembling(9), Canceling(10), Degrade(11), Crashed(12)

// synoUPS :  .1.3.6.1.4.1.6574.4
pas intéressant

// autres OIDs
	Load
.1.3.6.1.4.1.2021.10.1.2.1 = STRING: "Load-1"
.1.3.6.1.4.1.2021.10.1.2.2 = STRING: "Load-5"
.1.3.6.1.4.1.2021.10.1.2.3 = STRING: "Load-15"
.1.3.6.1.4.1.2021.10.1.3.1 = STRING: "1.96"
.1.3.6.1.4.1.2021.10.1.3.2 = STRING: "2.02"
.1.3.6.1.4.1.2021.10.1.3.3 = STRING: "2.04"
	Usage CPU
User			.1.3.6.1.4.1.2021.11.9.0 = INTEGER: 1
System			.1.3.6.1.4.1.2021.11.10.0 = INTEGER: 0
Idle			.1.3.6.1.4.1.2021.11.11.0 = INTEGER: 98
	Mémoire
memTotalSwap		.1.3.6.1.4.1.2021.4.3.0 = INTEGER: 3317676
memAvailSwap		.1.3.6.1.4.1.2021.4.4.0 = INTEGER: 3311992
memTotalReal		.1.3.6.1.4.1.2021.4.5.0 = INTEGER: 2035652
memAvailReal		.1.3.6.1.4.1.2021.4.6.0 = INTEGER: 114792
memTotalFree		.1.3.6.1.4.1.2021.4.11.0 = INTEGER: 3426784
?			.1.3.6.1.4.1.2021.4.12.0 = INTEGER: 16000
memShared		.1.3.6.1.4.1.2021.4.13.0 = INTEGER: 0
memBuffer		.1.3.6.1.4.1.2021.4.14.0 = INTEGER: 37300
memCached		.1.3.6.1.4.1.2021.4.15.0 = INTEGER: 1585848
	Reseau
ifName			.1.3.6.1.2.1.31.1.1.1.1
ifHCInOctets		.1.3.6.1.2.1.31.1.1.1.6
ifHCOutOctets		.1.3.6.1.2.1.31.1.1.1.10

src: Synology_DiskStation_MIB_Guide.pdf

Logiciels

Pour ajouter des fonctionnalités supplémentaires sur le NAS, on peut installer des logiciels. Comme sur les distribs Linux, on les installe depuis des dépôts, que l'on peut personnaliser dans l'interface de l'outil idoine : le Package Center. On dispose par défaut des paquets dans le dépôt officiel Synology, mais on peut en rajouter d'autres dans Settings/Package Sources, par exemple :

synogear

Certains outils de base des distributions Linux sont installables en CLI avec la commande synogear : 

# installation, en root (sudo)
synogear install
 download DiagnosisTool 3.0.1-3008 successfully
 
# lister les composants installés
synogear list

On retrouvera par exemple iperf, dig, iostat, tcpdump, tracepath, tmux etc…

Tiny Tiny RSS

C'est un client RSS ; il dépend du paquet MariaDB (dont le mdp root est vide par défaut).

MySQL root password

Depuis la version DSM 6, TT RSS ne se lance plus (avec l'erreur : “incorrect MySQL root password”) ; pour corriger le problème il faut se connecter en SSH (avec un compte ayant les droits d'admin) et saisir : 

sudo mkdir -p /usr/syno/mysql/bin
sudo ln -s /usr/bin/mysql /usr/syno/mysql/bin/mysql

Flux non MAJ

Toujours en DSM 6, les flux ne se mettent pas à jour. En remplaçant le chemin vers l'exécutable PHP dans la conf du paquet tt-rss, ça fonctionne : 

vi /var/services/web/tt-rss/config.php
 
//define('PHP_EXECUTABLE', '/usr/bin/php');
define('PHP_EXECUTABLE', '/usr/local/bin/php56');

Puis redémarrer le paquet tt-rss via l'interface web (dans le “Package center, Tiny tiny RSS, Action: Stop” puis Start).

Audio Station

Audio station permet d'écouter dans un navigateur la musique stockée sur le NAS ; pour cela elle se base sur les dossiers indexés contenant de la musique (par défaut /Music). Pour changer ce répertoire par défaut ou ajouter d'autres dossiers contenant de la musique :

Pour qu'un utilisateur puisse utiliser Audio Station, aller dans le Panneau de configuration/Utilisateur ; cliquer sur l'utilisateur puis sur l'onglet Applications, et vérifier les droits.

Jellyfin

Logiciel de catalogue et lecteur multimédia en mode web. Dockerisable, Jellyfin existe en paquet SynoCommunity plus simple à installer (à accompagner avec le paquet ffmpeg, qui est proposé par l'assistant).

Avec DSM 7 il faut octroyer les droits d'accès au répertoire multimédia à l'utilisateur interne sc-jellyfin : pour cela aller dans le panneau de configuration> Dossier partagé ; clic droit sur le dossier> Modifier. Dans la fenêtre, choisir l'onglet Permissions, choisir dans la selectbox “Utilisateur du système interne” et donner les droits en Lecture seule l'utilisateur sc-jellyfin.

Virtualisation

A l'heure ou j'écris ces lignes la virtualisation est en version bêta, et non supportée sur les DS415+. Et de toute façon ils n'ont pas suffisamment de RAM (2 Go), comme indiqué dans les prérequis officiels.

En pratique on peut quand même tester le Virtual Machine Manager fraîchement pondu par Synology, moyennant :

Upgrade de la RAM

De base le boitier dispose de 2 Go de mémoire vive, ce qui est suffisant pour la grande majorité des utilisations. Cependant si l'on souhaite goûter à la joie de la virtualisation, il faut passer à 8 Go (maximum supporté sur le seul emplacement so-dimm de la carte mère). J'ai personnellement utilisé la barrette suivante : Crucial 8GB Single DDR3/DDR3L 1600 MT/S (PC3-12800) Unbuffered SODIMM 204-Pin Memory - CT102464BF160B, qui est celle la plus recommandée ça et là.

L'augmentation de la capacité mémoire n'est pas supportée par Synology sur ce modèle ; de ce fait on perd la garantie constructeur quand on ouvre le boitier. Ce dernier n'est pas conçu pour être ouvert facilement, mais c'est quand même largement accessible même par Mme Michu : il suffit de se munir d'un tournevis cruciforme.

FIXME insérer des images ici

Pour l'ouverture du boitier j'ai suivi ce modop de Charles Hooper.

Une fois la mémoire ajoutée, on pourra vérifier sa bonne prise en compte dans le Centre d'info :

Virtual Machine Manager

Normalement comme tous les paquets en bêta, Virtual Machine Manager n'apparait qu'en ayant coché la case “Oui je veux voir les versions bêta” dans les paramètres du Centre de Paquets. Mais pour les DS415+ il n'y est pas car pas officiellement supporté. Il faut donc installer le fichier .spk en téléchargeant la dernière version ici : https://usdl.synology.com/download/Package/spk/Virtualization/ ; puis cliquer sur “Installation manuelle”, et enfin sélectionner le fichier téléchargé.

Le paquet est ensuite disponible dans le menu principal :

Docker

Pour installer Docker, aller dans Centre de paquets > Docker > Installer

Installer pihole

Une fois Docker, installer, le lancer ;

Pour la configuration, procéder comme suit : 

#Fichier/Dossier         Chemin d'accès
docker/pihole/dnsmasq.d  /etc/dnsmasq.d
docker/pihole/pihole     /etc/pihole
# mot de passe de l'interface web
WEBPASSWORD=MDP4cc3sInterfaceWeb
 
# Spécifie au pihole de répondre à tous les clients qui lui demande
# Si on n'est pas sûr de ce que l'on veut faire, il vaut mieux préciser "local"
# que "all", c'est plus sécure.
DNSMASQ_LISTENING=all
 
# port d'écoute de l'interface web du pihole
WEB_PORT=8080
 
# bind le serveur web sur toutes les adresses locales du NAS
#ServerIP=0.0.0.0
 
 
# si vous avez configuré un DNS pour votre Syno, vous pouvez le préciser ici
VIRTUAL_HOST=pihole.local.perso
 
# dans mon cas j'ai déjà un résolveur DNS, donc je le spécifie ici. Sinon, ne pas ajouter cette ligne
PIHOLE_DNS_=192.168.1.65
# on peut préciser plusieurs forwarders séparés par un ";", et spécifier le port d'écoute avec #<PORT>
PIHOLE_DNS_=192.168.1.65#5353;80.67.169.12;80.67.169.40

On clique sur Action > Démarrer et c'est parti, on peut logiquement accéder à l'interface web du pihole à partir sur http://IP_DU_SYNO:8080

A noter que si on choisit de changer des variables d'environnement après un premier lancement du conteneur, ça risque de planter car il semble qu'elles soient enregistrées dans une base du pihole ; dans mon cas par exemple j'ai voulu ajouter VIRTUAL_HOST à postériori, le conteneur n'a jamais voulu redémarrer en ma crachant le log : 

::: Testing lighttpd config: Error: duplicate array-key: VIRTUAL_HOST. Please get rid of the duplicate entry.

Pour contourner cela, sélectionner le conteneur puis : “Paramètres > Paramètre en double”. Cela permettra de modifier les variables d'environnement tout en conservant les données partagées sur les volumes.

Mise à jour du conteneur

Globalement la procédure consiste à arrêter le conteneur, le supprimer, supprimer l'image locale, puis à télécharger la dernière image “latest”, et enfin recréer le conteneur. Pour automatiser la re-création du conteneur, on peut créer le user-script suivant dans le planificateur de tâche du syno (à lancer en root, et en désactivant la répétition pour ne le lancer que manuellement) : 

docker run -d --name=pihole-new \
-e WEB_PORT=3443 \
-e WEBPASSWORD=MDP4cc3sInterfaceWeb \
-e DNSMASQ_LISTENING=local \
-e VIRTUAL_HOST=pihole.local.perso \
-e PIHOLE_DNS_=127.0.0.1#1053;192.168.1.65 \
-e TZ=FR \
-v docker/pihole/dnsmasq.d:/etc/dnsmasq.d \
-v docker/pihole/pihole:/etc/pihole \
--net=host \
--restart=unless-stopped \
pihole/pihole

Ressources :

Docs docker

Hyperbackup

Mise en place d'une sauvegarde Hyperbackup sur un NAS Synology vers un serveur rsync “compatible” (pas Synology) via SSH (en l'occurence un NAS OpenMediaVault v5).

Sur le serveur OMV distant : * créer un nouveau partage “bck-syno” dans Access Right Manager> Shared Folder * activer le SSHd et créer un utilisateur “usr-hbkp” ; l'ajouter dans le groupe SSH * activer le service rsyncd : dans Services> Rsync

Sur le NAS Syno source, installer puis lancer “Hyper Backup” ; puis créer une nouvelle sauvegarde : Serveur de fichier/Rsync :

Lancer la sauvegarde. Les fichiers rsyncd.conf et rsyncd.secrets seront créés dans le dossier distant.

Tips

Installer les plugins OMV-extra

Vu ici : https://forum.openmediavault.org/index.php?thread/5549-omv-extras-org-plugin/ 

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

Connexion SSH

Pour se connecter en SSH au NAS, il faut activer le service dans le Panneau de configuration > System : Terminal & SNMP. Puis on s'y connecte soit avec le login “admin”, soit “root”. Le mot de passe est toujours celui du compte admin donc choisissez-le judicieusement.

NB : Depuis DSM 6, on ne peut plus se connecter avec le login root, il faut se connecter avec un compte utilisateur ayant les droits d'admin. Puis utiliser sudo.

Certificat SSL/TLS let's encrypt

Pour renouveler son certificat let's encrypt (qui n'est valide que 3 mois) : 

sudo /usr/syno/sbin/syno-letsencrypt renew-all -v
 
DEBUG: Issuer name of certificate. [Let''s Encrypt]->[/usr/syno/etc/certificate/_archive/JjujoD/cert.pem]
DEBUG: Issuer name of certificate. [Synology Inc.]->[/usr/syno/etc/certificate/_archive/lx0mfJ/cert.pem]
DEBUG: certificate is not issued by Let''s encrypt. [/usr/syno/etc/certificate/_archive/lx0mfJ/cert.pem]
DEBUG: start to renew [/usr/syno/etc/certificate/_archive/JjujoD].
DEBUG: setup acme url https://acme-v02.api.letsencrypt.org/directory
DEBUG: GET Request: https://acme-v02.api.letsencrypt.org/directory
DEBUG: GET Request: https://acme-v02.api.letsencrypt.org/acme/new-nonce
DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/new-order
DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/new-order
DEBUG: Failed to port map router detect. [1]
DEBUG: failed to open port 80.
DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850
DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850
DEBUG: dns-01 is not support for toto.fr
DEBUG: Setup challenge for toto.fr with type http-01
DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/chall-v3/41127559850/iipDBw
DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/chall-v3/41127559850/iipDBw
DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850
DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850
DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850
DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850
DEBUG: ==> start new-cert.
DEBUG: generate csr & private key
DEBUG: get new-cert
DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/finalize/68533444/32870294000
DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/finalize/68533444/32870294000
DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/cert/038012c726f8b4e7d4fa059921e49ffb6546
DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/cert/038012c726f8b4e7d4fa059921e49ffb6546
DEBUG: get issuer-cert
DEBUG: save to files
DEBUG: renew success. [/usr/syno/etc/certificate/_archive/JjujoD].

(PS : le sudo -i marche aussi)

Et si KO : penser à ouvrir bien grand (permit any any) le firewall Syno, cf anecdote qui suit.

Erreur syno-letsencrypt

TL;DR : Le problème vient d'un filtrage géographique dans le firewall du Syno. Malgré que celui-ci soit désactivé, il bloque quand même les serveurs de letsencrypt. En créant une règle permissive (genre permit any en HTTP) on fait tomber le script en marche !

Je suis récemment tombé sur un os lors du renouvellement de mon certificat letsencrypt : alors que la redirection tcp/80 était bien en place sur mon routeur, le script se vautre en renvoyant l'erreur suivante : 

sudo /usr/syno/sbin/syno-letsencrypt renew-all -v
[..]
DEBUG: DNS challenge failed, reason: {"error":108,"file":"challenge.cpp","msg":"Not synology DDNS."}
DEBUG: Normal challenge failed, reason: {"error":200,"file":"client.cpp","msg":"new_authz: unexpect httpcode."}

Sympa l'erreur : “unexpect httpcode”. Bon.

On passe en mode Columbo : on désactive le firewall du Syno et on relance le script avec l'option debug de la dernière chance (syno-letsencrypt -vv) ; on voit que notre Syno génère un fichier de “challenge” et le mettre à disposition des serveurs letsencrypt : 

# morceaux choisis du debug :
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "Fetching http://mydomain.com/.well-known/acme-challenge/YuOX1zXw-\
lD20Th6mHJzDNhBDkURHo1ZFBHxh5F-A-0: Timeout during connect (likely firewall problem)",
        "status": 400
      }

Ce challenge permet de valider que :

Ce fichier est mis à disposition en HTTP par le serveur nginx du Syno : 

grep -Ri -A3 "acme-challenge" /etc/nginx/*
/etc/nginx/nginx.conf-        location ^~ /.well-known/acme-challenge {
/etc/nginx/nginx.conf:            root /var/lib/letsencrypt;
/etc/nginx/nginx.conf-            default_type text/plain;
/etc/nginx/nginx.conf-        }

C'est bourrin mais ça paie : le dossier est bien configuré dans nginx, et il est situé “en vrai” dans /var/lib/letsencrypt/.well-known/acme-challenge/ !

Le dossier existe bel et bien et dispose des bons droits, mais en fouinant dans les logs d'erreur du serveur nginx du Syno, je trouve ceci : 

2018/11/02 15:35:20 [error] 6972#6972: *51124 access forbidden by rule, client: 64.78.149.164, server: _, request: \
"GET /.well-known/acme-challenge/56f1J6p6Wf3o-g219MmcZS7tCNufwA1Dj1Dm-ddGy1Y HTTP/1.1", host: "mydomain.com"

J'aime les erreurs “access forbidden by rule”, ça m'aide beaucoup : je n'ai jamais défini de règle de filtrage dans nginx et il n'y en a pas sur ce dossier…

Les fichiers de challenge sont temporaires et supprimés à la fin du script ; aussi on va faire le test avec un autre fichier : 

echo "TEST" > /var/lib/letsencrypt/.well-known/acme-challenge/test

Puis, j'appelle le fichier depuis mon navigateur ou un wget : 

wget -d http://mydomain.com/.well-known/acme-challenge/test
[..]
2018-11-02 16:21:06 (121 KB/s) — « test » sauvegardé [5/5]

Et là ça passe !

C'est donc un filtrage en fonction de l'IP source ; n'ayant rien à perdre, je réactive le pare-feu de mon Syno et supprime le filtrage géographique (le champ “emplacement” dans la conf du firewall) : en mode “permit any any”. Je relance le script… 

/usr/syno/sbin/syno-letsencrypt renew-all -v
[..]
DEBUG: renew success. [/usr/syno/etc/certificate/_archive/OufCaMarche].

… et BIM ça marche !

Aussi saugrenu que ça paraisse^W soit, chez Synology quand on décoche la case “Activer le pare-feu”, ben ça vaut pas dire que ça le désactive (même après reboot du NAS) ! Par ailleurs vu que c'est de l'iptables, c'est étonnant que cela puisse arriver dans les logs nginx…

Mais ma curiosité s'arrête là ; à dans 3 mois !

Erreur find en tâche planifiée

Description du problème : un script utilisant l'outil find, et qui se lance sans problème en CLI, ne s'exécute pas normalement lorsqu'il est lancé en tant que tâche planifiée (pourtant sous le même utilisateur) ; le message d'erreur est :

find: cannot get current directory: Permission denied

D'après ce thread sur stackoverflow, cela viendrait de l'implémentation du find sur ce système ; quoiqu'il en soit l'astuce indiquée du cd /tmp juste avant l'appel à find fonctionne à merveille pour moi.

Liens