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 mais il suffit tout simplement de copier le dit fichier avec cp ou, par exemple, “copy” de AutoTools dans ruTorrent voir de mettre ce montage en dossier final pour les téléchargements via SABnzbd/NZBget.

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

1. Risques et limites 
2. Principe
3. Installation de FUSE
4. Installation de rClone
5. Configuration de rClone, remote non chiffré
6. Test
7. Configuration de rClone, remote chiffré
8. Tests
9. Exemple d’organisation/utilisation
10. Tweaks rClone
11. Scripts
12. Synology
13. Montage des remotes sur d’autres machines

Risques & limites

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. 

FUSE

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

Configuration de rClone

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

Petits tests

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 🙂

Chiffrement

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.

Tadaaaa !!!

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.

Tweaks rClone

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).

Scripts divers

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

Synology

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.