rClone : stockage chiffré Amazon Cloud Drive pour Emby/Plex/Kodi/Cloud
Sur le marché actuel du stockage en ligne il n’existe pas de meilleur rapport espace/prix qu’Amazon Cloud Drive avec son offre de stockage illimité pour 70$/an. Bien entendu la notion d’illimité peut assurément être conditionnée du jour au lendemain par Amazon mais avec des “si” on ne fait rien.
Une fois monté sur mon PC, mon espace de stockage ACD m’indique 100To d’espace libre. Certes 100To ce n’est pas “illimité” mais une machine ne sachant pas afficher cette notion on fera avec. Puis d’ici à ce que je les remplisse j’ai le temps d’aviser… :)
MàJ : Sachez que depuis un bon mois rClone supporte désormais l’écriture pour Amazon. Concrètement cela veut dire que pour copier un fichier sur un Amazon chiffré il n’est plus nécessaire d’exécuter une commande du type rclone copy
Et si on l’utilisait pour y stocker du contenu multimédia ?
Emby (ou Plex) est un gestionnaire de contenus (audio, vidéo, livres, notamment) qui permet de streamer, transcodé ou non, depuis un serveur dédié, un VPS ou un simple PC qui fait office de serveur. Kodi est un gestionnaire multimédia plutôt à usage local.
Imaginez stocker en ligne tous vos contenus, sans limite d’espace, et pouvoir les lire depuis n’importe quel endroit pour peu que vous ayez une connexion Internet, pour le prix mensuel d’un bon serveur dédié de 11-12To en RAID0 et donc sensible aux pannes/crash disque. Le Cloud d’Amazon permettant en effet ne pas craindre la perte de données.
Dans ce tutoriel j’utilise Emby, sur un VPS personnel : Debian8 Ubuntu16 nu (rClone FUSE fonctionne mal avec Debian chez moi), 2CPU, 4GO RAM & 100Go d’espace disque. Si j’avais la ligne Internet adéquate je pourrais également monter mon ACD/déchiffré sur mon “PCTV” où se trouve Kodi et il pourrait alors lire directement le contenu depuis mon cloud.
Pour info, il ne semble pas possible de monter un espace chiffré via rClone sur Windows.
Sommaire
- Risques et limites
- Principe
- Installation de FUSE
- Installation de rClone
- Configuration de rClone, remote non chiffré
- Test
- Configuration de rClone, remote chiffré
- Tests
- Exemple d’organisation/utilisation
- Tweaks rClone
- Scripts
- Synology
- Montage des remotes sur d’autres machines
Il faut chiffrer !
Evidemment Amazon est un GAYFAM (Y=Yahoo). Evidemment Amazon lutte contre la contrefaçon. Evidemment, que ce soit du Cloud perso/pro, du légal ou non, c’est du bon sens que de chiffrer votre contenu afin de le préserver des éventuels regards indiscrets, voire des bots à la recherche de fichiers sous copyright (revendiqués par Amazon).
Si on parle de données personnelles (Cloud perso) le système de chiffrement importe peu et libre à chacun d’utiliser ce qu’il souhaite. Le principal étant que la clé de déchiffrement ne se trouve pas sur le cloud.
En ce qui concerne le contexte de ce tutoriel, à savoir des données multimédia devant être accessibles par un logiciel d’indexation/lecture tiers, il y a 2 solutions : utiliser ACD_cli (Amazon Cloud Drive en lignes de commande) et chiffrer via encFS (une sur-couche système chiffrée) ou rClone (rSync pour les Clouds). Et évidemment il faut chiffrer d’une part (stockage) et déchiffrer d’une autre (indexation/lecture).
Il faut faire ça en bonne intelligence
En effet si Amazon propose de l’illimité c’est qu’évidemment ils comptent sur le fait que nous ne seront pas des milliers à réellement “taper dedans”. Le fait de chiffrer le contenu peut représenter en soi une alerte alors si c’est pour stocker plusieurs 10aines de To en balançant/récupérant chaque jour à fond depuis plusieurs serveurs 1Gbps on peut penser que ça va leur mettre la puce à l’oreille.
Personne n’est dupe et à moins de faire ça via un compte professionnel qui va aller croire qu’un particulier a 20, 50, 80To de données personnelles ? Faut pas non plus les prendre pour ce qu’ils ne sont pas.
Certains disent s’en servir de seedbox, ce qui me semble assez risqué
Comme pour l’exemple du dessus, une SB génère par défaut beaucoup d’I/O de données, et c’est à mon sens tout sauf discret. Je dirais donc que c’est à utiliser avec parcimonie, du genre stockage de très long terme pour WCD mais pas pour du DL/UP “classique”.
Veillez à ne pas indexer tous vos contenus d’un coup via Emby, Plex, Kodi
Ou tout autre logiciel qui pourrait aller chercher des infos sur votre ACD. C’est le même principe qu’au-dessus : indexer un contenu = faire des appels à l’API Amazon = ça se voit = risque de se faire couper son accès si trop fréquent/important. J’ai récemment lu le cas d’un utilisateur qui s’est fait bloquer son compte suite à l’indexation de 2To de contenu. Alors que d’autres disent avoir balancé 5To d’un coup et indexé ensuite, sans souci. Là encore… c’est aléatoire mais ça peut arriver.
Perso je suis monté à 3To lors de ma précédente installation, sans problème.
Défauts de synchronisation
Il y a des pertes intempestives de connexion avec ACD lors de l’upload de gros fichiers (10Go+ et il semble même qu’ACD ne supporte pas les fichiers de plus de 50-60Go). En cas d’erreur il faut synchroniser à la main. En utilisant le combo ACD_cli/encFS l’idéal est de mettre en place un script qui contrôle et au besoin démonte/remonte/réupload le dit contenu. La bonne nouvelle est que rClone comprend des options permettant d’éviter ce souci, dans la plupart des cas.
Veillez à vous servir d’une machine qui ne souffre pas de limite de trafic et soit suffisamment puissante
En effet, par exemple, un fichier de 1Go va générer 3Go de trafic :
– Lorsqu’il est envoyé/téléchargé sur la machine,
– Lorsqu’il est envoyé sur Amazon, une fois chiffré,
– Lorsqu’il est lu, donc téléchargé depuis Amazon.
De même, le chiffrement et la lecture vont pomper pas mal de ressources CPU/RAM. Sans compter que très souvent la lecture va induire un transcodage à la volée. Le tout consommant beaucoup de ressources CPU. Au besoin on peut toujours utiliser 2 machines distinctes : 1 pour chiffrer/uploader et l’autre pour indexer/lire/transcoder le contenu.
Fonctionnement
Comme nous le verrons par la suite il va falloir procéder en 2 temps :
– Créer une liaison avec le Cloud Amazon, permettant de déposer/prendre des fichiers,
– Mettre en place le chiffrement/déchiffrement de cette liaison. Le tout via rClone.
Pour ceux qui connaissent c’est comme un conteneur chiffré True/VeraCrypt qu’on stockerait sur Amazon.
Pour monter un dossier rClone utilise FUSE.
Notez que dans le cas de VPS il faut auparavant activer le module Fuse. Rapprochez-vous de votre hébergeur/doc pour savoir quelle est la manip (qui diffère selon le système et l’hébergeur…).
Si vous êtes comme moi sur ProxMox, en LXC, il y a plusieurs méthodes pour activer Fuse sur un conteneur.
SOIT Pour l’activer sur votre CT, éditez son fichier de configuration sur l’hôte (CT stoppé) et ajoutez ce qui suit à la fin :
nano /etc/pve/lxc/XXX.conf
lxc.autodev: 1
lxc.hook.autodev: sh -c "mknod -m 0666 ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229"
Relancez votre VPS et vérifiez
root@Amazon:~# ps aux | grep fuse root 1675 0.0 0.0 11128 980 pts/2 S+ 10:48 0:00 grep fuse
SOIT Activez-le sur votre hôte (serveur Proxmox), en root :
modprobe fuse
Puis sur votre conteneur :
mknod -m 666 /dev/fuse c 10 229
Et installez FUSE (s’il n’est pas déjà présent)
apt-get install fuse
Pour démonter un dossier
root@Amazon:~# fusermount -u /Dossier/de/montage => root@Amazon:~# fusermount -u /mnt/ACD/
Installation de rClone (Debian/*buntu etc)
Vous aurez besoin de wget et unzip. Dans cet exemple je prends la version 64bits (AMD64), adaptez à votre configuration.
wget http://downloads.rclone.org/rclone-current-linux-amd64.zip unzip rclone-current-linux-amd64.zip cd rclone-*-linux-amd64 sudo cp rclone /usr/sbin/ sudo chown root:root /usr/sbin/rclone sudo chmod 755 /usr/sbin/rclone
Pour cet article j’utilise la version 1.34 compilée depuis les sources.
root@Amazon:~# rclone -V 2016/11/15 11:05:12 Failed to load config file "/root/.rclone.conf" - using defaults: open /root/.rclone.conf: no such file or directory rclone v1.34
rclone config
Ajouter un “remote” (n)
No remotes found - make a new one n) New remote s) Set configuration password q) Quit config
Que je nomme, débordant de créativité (…) : ACD_Emby
name> ACD_Emby
Sélectionner le Cloud ACD (1)
Choose a number from below, or type in your own value 1 / Amazon Drive \ "amazon cloud drive" Storage> 1
Puis ne rien mettre et passer (touche Enter)
Amazon Application Client Id - leave blank normally. client_id> Amazon Application Client Secret - leave blank normally. client_secret>
Et enfin refuser la configuration automatique (n)
Use auto config? * Say Y if not sure * Say N if you are working on a remote or headless machine y) Yes n) No
Et comme c’est écrit : il faut maintenant utiliser une machine disposant d’un navigateur.
For this to work, you will need rclone available on a machine that has a web browser available. Execute the following on your machine: rclone authorize "amazon cloud drive"
Mon serveur n’ayant pas de Desktop je repasse sur mon PC personnel. Il suffit d’installer rClone sur n’importe quel PC (Windows, OSX, Linux) et de lancer la commande donnée pour qu’un navigateur se lance sur http://127.0.0.1:53682/auth, qui est une interface de connexion Amazon Cloud Drive/rClone.
J’ai franchement aucune idée de ce à quoi ça peut ressembler sous Windows mais sous Linux/OSX ça donne ceci :
┬─[ayx@Aerya:~]─[14:55:22] ╰─>$ rclone authorize "amazon cloud drive" 2016/11/15 14:44:23 Failed to load config file "/home/ayx/.rclone.conf" - using defaults: open /home/ayx/.rclone.conf: no such file or directory If your browser doesn't open automatically go to the following link: http://127.0.0.1:53682/auth Log in and authorize rclone for access Waiting for code...
Got code
Paste the following into your remote machine --->
{"access_token":".......","token_type":"bearer","refresh_token":".......","expiry":"2016-11-15T15:57:00.314157161+01:00"}
┬─[ayx@Aerya:~]─[14:57:16]
On remarque au passage que ce token est utilisable 1h, ce qui laisse amplement le temps de tout copier/coller sur notre serveur, logiquement resté sur Then paste the result below: result>
Then paste the result below:
result> {"access_token":".....","token_type":"bearer","refresh_token":".....","expiry":"2016-11-15T15:57:00.314157161+01:00"}
--------------------
[ACD_Emby]
client_id =
client_secret =
token = {"access_token":".....","token_type":"bearer","refresh_token":".....","expiry":"2016-11-15T15:57:00.314157161+01:00"}
--------------------
Puis on valide (y) et nous avons maintenant notre Cloud ACD configuré avec rClone.
y) Yes this is OK e) Edit this remote d) Delete this remote y/e/d> y Current remotes: Name Type ==== ==== ACD_Emby amazon cloud drive e) Edit existing remote n) New remote d) Delete remote s) Set configuration password q) Quit config
Afin de vérifier que tout fonctionne bien nous allons copier un fichier via le “remote”, vérifier sa présence sur l’Amazon Cloud Drive, puis monter ensuite ACD via rClone sur le serveur.
Ici pas de cp/mv/rm, tout doit logiquement passer par rClone et ses commandes. Nous devons copier le fichier dans/avec le “remote” créé via rClone, donc ACD_Emby: Et j’insiste sur les : à mettre à la fin du nom de votre remote.
root@Amazon:~# rclone copy vid.mp4 ACD_Emby: 2016/11/15 19:29:16 amazon drive root '': Waiting for checks to finish 2016/11/15 19:29:16 amazon drive root '': Waiting for transfers to finish 2016/11/15 19:30:12 Transferred: 175.870 MBytes (3.074 MBytes/s) Errors: 0 Checks: 0 Transferred: 1 Elapsed time: 57.2s
Vérifions maintenant que la vidéo apparaît bien dans le Cloud
Pour terminer montons ACD sur le serveur. Pour le détail des paramètres je vous invite à lire la doc de rClone mount.
Il faut au préalable créer le dossier de montage local ; dans mon cas
mkdir /mnt/ACD
root@Amazon:/mnt# rclone mount ACD_Emby: /mnt/ACD/ --allow-other --no-modtime & [1] 15387 root@Amazon:/mnt#
Puis on peut vérifier que notre vidéo s’y trouve bien
root@Amazon:/mnt/ACD# ls vid.mp4 root@Amazon:/mnt/ACD#
Maintenant qu’on sait que tout est ok on peut démonter notre ACD
root@Amazon:~# cd ~ root@Amazon:~# fusermount -u /mnt/ACD root@Amazon:~#
Le dossier de montage est maintenant vide
root@Amazon:~# cd /mnt/ACD/ root@Amazon:/mnt/ACD# ls root@Amazon:/mnt/ACD#
Il ne vous aura pas échappé que vid.mp4 n’était pas chiffrée sur le Cloud :)
Il y a 2 notions de base :
– Les noms doivent être chiffrés. Si “on” peut trouver un fichier via son hash, c’est aussi le cas tout simplement via son nom,
– S’il faut chiffrer il faut aussi déchiffrer afin qu’Emby puisse l’indexer et en lire le contenu.
Avant j’utilisais donc encFS, pour lequel voici un bon tutoriel (anglais), utilisé avec ACD_cli. Pour plusieurs raisons dont les “bogues” de tailles d’uploads sur Amazon et la place prise par le processus (il faut avoir les sources, les chiffrer via encFS puis ensuite les envoyer sur ACD), j’ai préféré rClone à ce duo. Ce dernier restant néanmoins très efficace dans le cadre d’un Cloud personnel (où on rencontre rarement des fichiers de plus de 10Go).
rClone vient de nous servir à créer le “remote” ACD_Emby. Comme on l’a bien vu, cette liaison ne sert qu’à envoyer/récupérer des fichiers sur/depuis ACD sur notre machine, il n’y’a là aucune notion de chiffrement. Nous devons par conséquent ajouter une étape intermédiaire permettant de chiffrer tout ce qui va sur/vient de notre ACD_Emby. Et c’est là que rClone montre toute sa puissance puisqu’il permet de créer un “remote” pour en chiffrer un autre. Nous allons donc créer le “remote” ACD_Enc qui va chiffrer ACD_Emby.
On repart avec rClone config, qui me liste les remotes existants et ajoutons ACD_Enc
root@Amazon:~# rclone config Current remotes: Name Type ==== ==== ACD_Emby amazon cloud drive e) Edit existing remote n) New remote d) Delete remote s) Set configuration password q) Quit config e/n/d/s/q> n name> ACD_Enc
Cette fois-ci il faut sélectionner Encrypt/Decrypt (5)
Storage> 5
Pour se laisser l’opportunité d’ajouter plus tard d’autres dossier chiffrés différemment, voire pas du tout, il est préférable d’indiquer un dossier précis à chiffrer. Pour ça il suffit de mentionner son nom à la suite du remote => ACD_Emby:Enc (là encore vous découvrez mon immense originalité dans la recherche d’un nom de dossier !)
Remote to encrypt/decrypt. Normally should contain a ':' and a path, eg "myremote:path/to/dir", "myremote:bucket" or maybe "myremote:" (not recommended). remote> ACD_Emby:Enc
Puis activer le chiffrement des noms de fichiers
How to encrypt the filenames. Choose a number from below, or type in your own value 1 / Don't encrypt the file names. Adds a ".bin" extension only. \ "off" 2 / Encrypt the filenames see the docs for the details. \ "standard" filename_encryption> 2
rClone propose ensuite d’entrer ou de générer un mot de passe, je tente l’auto en 128bits. Notez de suite votre mot de passe dans un lieu sûr.
Password or pass phrase for encryption. y) Yes type in my own password g) Generate random password y/g> g Password strength in bits. 64 is just about memorable 128 is secure 1024 is the maximum Bits> 128 Your password is: KF6-hfXAur0B7VjeLcB3Mw Use this password? y) Yes n) No y/n> y
Même chose pour le salage
Password or pass phrase for salt. Optional but recommended. Should be different to the previous password. y) Yes type in my own password g) Generate random password n) No leave this optional password blank y/g/n> g Password strength in bits. 64 is just about memorable 128 is secure 1024 is the maximum Bits> 128 Your password is: FopwRFVbQIDdjY6GFPor0H Use this password? y) Yes n) No y/n> y
Notez au passage qu’utiliser les mêmes mots de passe pour un autre remote (pour le même espace de stockage) permettra d’accéder aux données de ce remote. Le chiffrement est bien entièrement dépendant des 2 pwds, uniquement.
Confirmer le tout et sauvegarder
Remote config -------------------- [ACD_Enc] remote = ACD_Emby:Enc filename_encryption = standard password = *** ENCRYPTED *** password2 = *** ENCRYPTED *** -------------------- y) Yes this is OK e) Edit this remote d) Delete this remote y/e/d> y Current remotes: Name Type ==== ==== ACD_Emby amazon cloud drive ACD_Enc crypt e) Edit existing remote n) New remote d) Delete remote s) Set configuration password q) Quit config e/n/d/s/q> q
J’ai mes 2 remotes ! \o/ Testons !
root@Amazon:~# rclone copy vid.mp4 ACD_Enc: 2016/11/16 08:49:32 Encrypted amazon drive root 'Enc': Waiting for checks to finish 2016/11/16 08:49:32 Encrypted amazon drive root 'Enc': Waiting for transfers to finish 2016/11/16 08:50:01 Transferred: 175.870 MBytes (5.814 MBytes/s) Errors: 0 Checks: 0 Transferred: 1 Elapsed time: 30.2s root@Amazon:~#
Montage du remote chiffré ACD_Enc sur le serveur. Que je monte dans le dossier (à créer) /mnt/Enc_ACD. Ouais je sais, je suis toujours très inventif sur les noms…
root@Amazon:/mnt# rclone mount ACD_Enc: /mnt/Enc_ACD/ -v --allow-other --no-modtime & [1] 17836 root@Amazon:/mnt# 2016/11/16 09:12:10 rclone: Version "v1.34" starting with parameters ["rclone" "mount" "ACD_Enc:" "/mnt/Enc_ACD/" "-v" "--allow-other" "--no-modtime"] 2016/11/16 09:12:11 Encrypted amazon drive root 'Enc': Modify window not supported 2016/11/16 09:12:11 Encrypted amazon drive root 'Enc': Mounting on "/mnt/Enc_ACD/" 2016/11/16 09:12:11 Encrypted amazon drive root 'Enc': Root()
Vérification du déchiffrement “à la volée”
root@Amazon:~# cd /mnt/Enc_ACD/ root@Amazon:/mnt/Enc_ACD# ls vid.mp4 root@Amazon:/mnt/Enc_ACD#
Montage du remote non chiffré ACD_Emby (toujours dans /mnt/ACD)
root@Amazon:~# rclone mount ACD_Emby: /mnt/ACD/ -v --no-modtime --allow-other & [1] 17930 root@Amazon:~# 2016/11/16 09:16:07 rclone: Version "v1.34" starting with parameters ["rclone" "mount" "ACD_Emby:" "/mnt/ACD/" "-v" "--no-modtime" "--allow-other"] 2016/11/16 09:16:08 amazon drive root '': Modify window not supported 2016/11/16 09:16:08 amazon drive root '': Mounting on "/mnt/ACD/" 2016/11/16 09:16:08 amazon drive root '': Root()
Vérification : j’ai toujours mon fichier vid.mp4 m’ayant servi lors d’un précédent test, j’ai aussi maintenant mon dossier /Enc dont le contenu est bien chiffré. Parfait !
root@Amazon:~# cd /mnt/ACD/ root@Amazon:/mnt/ACD# ls Enc vid.mp4 root@Amazon:/mnt/ACD# cd Enc/ root@Amazon:/mnt/ACD/Enc# ls ld0rggd8eihacfib55rmob69i0 root@Amazon:/mnt/ACD/Enc#
Il n’y a pas besoin de démonter/remonter un remote (chiffré ou non) suite à la copie ou au déplacement d’un fichier dedans, on le voit de suite.
Nous avons maintenant tout ce qu’il faut pour envoyer du contenu chiffré sur Amazon Cloud Drive et le parcourir/lire déchiffré via le montage du remote chiffré sur une machine. Dans ce contexte précis, seul le montage du remote chiffré ACD_Enc est utile et le dossier /mnt/Enc_ACD/ servira de source pour Emby, Plex, Kodi etc.
Libre à vous de l’organiser comme vous voulez :
– 1 seul remote ACD_Enc: contenant /Enc/Séries, Enc/Films etc,
– ou autant de remote chiffrés que de “sources => Series_ACD_Enc: qui dépose dans ACD/Enc/Series, Films_ACD_Enc: qui dépose dans ACD/Enc/Films etc.
On peut toujours monter ACD_Emby: pour y stocker des données en clair, qui seront stockées à côté de /Enc, par exemple pour partager rapidement un fichier avec un ami.
Pour les fans d’automatisation comme moi, et je m’y attellerai selon mon temps libre, je pense que le plus simple geek est la configuration suivante.
Bien évidemment tout ça est encore en plein développement (rClone comme ACD) et ce n’est pas fiable à 100% dans le transfert des données. Du moins pour des fichiers supérieurs à 10Go.
Du coup l’équipe de rClone ajoute quelques options bien utiles (consultez les docs move/copy notamment) et bosse visiblement pas mal sur les différentes remontées des utilisateurs. Il semble que Plex/emby rencontrent toujours un souci en avance/retour rapide.
Voici les options de base que j’ai tendance à utiliser :
– Test de paramètres (opération à blanc), que je fais systématiquement avant de mettre en place un script rClone,
– Limitation de la bande passante, afin de ne pas pourrir les débits des autres VPS sur ma machine. J’utilise un autre VPS avec Emby, que je ne bride pas,
– Définition de l’emplacement du fichier de configuration, que je stocke (avec toutes mes config) dans /confz,
– Log des actions, vu que parfois ça plante c’est toujours utile,
– Retry, je mets 5, que rClone puisse réessayer 5 fois un transfert en cas de coupure,
– Limitation du transfert en parallèle à 2 fichiers, dans mon cas du fait de ma limitation intentionnelle de la bande passante allouée à ce VPS,
– Désactivation du timeout, pour que mon serveur ne se déconnecte pas d’ACD pour éviter les défauts de copie/déplacement.
Et les options spécifiques à Amazon Cloud Drive (pour fichiers de plus de 10Go etc).
Montage automatique des remotes (ou que du chiffré, à vous de voir/modifier)
Créer un fichier montageACD.sh
#!/bin/bash # Montage remote ACD chiffré rclone mount ACD_Enc: /mnt/Enc_ACD/ --allow-other --no-modtime & # Montage remote ACD global rclone mount ACD_Emby: /mnt/ACD/ --allow-other --no-modtime &
L’exécuter via sh montageACD.sh ou le lancer au boot via CRON (crontab -e en root et ajouter)
@reboot sh /chemin/vers/montageACD.sh
Démontage des remotes
Créer un fichier demontageACD.sh
#!/bin/bash # Démontage remote ACD chiffré fusermount -u /mnt/Enc_ACD/ # démontage remote ACD global fusermount -u /mnt/ACD/
L’exécuter via sh demontageACD.sh
Script Python qui avertit d’un problème et remonte les remotes
Exemple, via PushBullet, à lire ici
Scripts Bash de lancement auto de rClone
Dispo sur GitHub, peuvent servir de base pour créer un système qui check les nouvelles sources et lance une copie ou un déplacement via rClone
Il n’existe pas, pour l’instant, de version de rClone pour Synology “mais” on peut contourner ce problème en installant rClone sur un système (Debian) en parallèle au DSM de Synology. J’avais fait un article à ce sujet.
Grand merci à Lolvince qui teste de son côté :)
en faite rclone fonctionne parfaitement depuis SSH, l’erreur est liée au montage via fuse.
le problème est identique avec la dernière version stable dispo sur une Debian. donc le souci est ici purement lié au dev de rClone sur la fonction mount et non sur une compatibilité Syno, ce qui promet de belles surprises dans un avenir plus ou moins proche
pour info le mount fonctionne très bien en lecture seule, il est reconnu que pour le moment l’écriture pose problème pour tous les Clouds.j’ai réglé mon problème de droit sur mon NAS avec l’option ” –allow-other” qui permet aux différents services d’accéder au dossier monté !je peux donc maintenant lire un film MKV de 9Go en live depuis un de mes PC, via un dossier partagé sur le réseau de mon NAS (N40L, xpenology)pour information le trafic généré sur ma connexion Internet est de 16Mo/sec en moyenne, et le process rClone (montage et decryptage) tourne au MAX de 25% sur 1 de mes 2 cores ce qui est très bien.donc pour le moment à part l’écriture via mount qui est en cours d’amélioration, le reste est exploitable !voici la ligne de commande qui permet de bons résultats :
./rclone mount --max-read-ahead 200M --checkers 300 --read-only --allow-other Amazon_Crypt: /volume1/video/Crypt/
Montage sur une autre machine (Linux, BSD, OSX)
J’ai aussi pour ambition de pouvoir accéder à mes contenus depuis Kodi, voire de mon laptop. De fait voici comment le faire sur un PC (Archlinux ici). Installez rClone et copiez votre fichier de configuration Serveur qui est, si vous n’avez rien touché, /home/USER/.rclone.conf ou /root/.rclone.conf
Recopiez-le sur votre “nouvelle” machine, soit au même endroit soit ailleurs vu qu’on peut préciser à rClone où il se trouve.
Il ne reste qu’à monter le “remote” chiffré (chez moi ACD_Enc) localement, avec son fichier de configuration.
┬─[ayx@Aerya:/mnt]─[17:00:57] ╰─>$ sudo mkdir /mnt/Enc_ACD/ ┬─[ayx@Aerya:/mnt]─[17:01:08] ╰─>$ sudo chmod -R 777 Enc_ACD/ ┬─[ayx@Aerya:~]─[17:01:52] ╰─>$ rclone mount ACD_Enc: /mnt/Enc_ACD/ --config=/home/ayx/Documents/CloudStation/.rclone.conf --no-modtime & ┬─[ayx@Aerya:/mnt]─[17:02:12] ╰─>$ cd Enc_ACD/ ┬─[ayx@Aerya:/mnt/Enc_ACD]─[17:02:16] ╰─>$ ls vid.mp4 ┬─[ayx@Aerya:/mnt/Enc_ACD]─[17:02:17] ╰─>$
J’ai donc monté uniquement le dossier /Enc de mon Amazon Cloud Drive et non l’ensemble du Cloud.
