A web-based GUI for rclone rcd (remote control daemon), somewhat implementing a concept of a two-panel file manager like Norton Commander, Total Commander or Far Manager. It can be used for rclone rcd running either on a local machine or on a remote host.
Commands are executed via HTTP requests (XMLHttpRequest), which are sent to a running rclone rcd using rc API.
- listing files and directories
- copying files and directories
- moving files and directories
- deleting files and directories
- creating a new directory
The sync/sync command support isn't implemented, and that is intentional. Comparing to moving/deleting, the syncing operation is a weapon of mass destruction and can cause severe data loss, so I decided not to have it available in the GUI. Adding support for it is likely to be very trivial, so you most probably will be able to do it yourself, but don't send it as a pull request to this repository as it will be rejected.
I have a remote seedbox and a local media server (running on Raspberry Pi), and I need to transfer files from seedbox to media server (via SFTP). And rclone is perfect for that, thanks to its rc mode, it only needs to have some remote GUI, so I could conveniently control it from my computers/tablets/smartphones.
More details about the use-case are in this article.
This project is inspired by another web-based GUI for rclone rc - rclone-webui-react, which provides a very good and nice-looking GUI - big thanks to its creator. But I was not entirely happy with it, as it has (or at least it had back in March 2020) several inconveniences:
- no queue, so all the transfers go in parallel;
- no way to cancel a transfer;
- the GUI feels a bit overloaded and has several non-functioning controls;
- transfers list has no sorting, so its elements "jump" one position to another on every view update.
So my goal was to improve these points. Although cancelling a transfer turned out to be the issue that originates in the rclone itself.
Having a fancy GUI was/is the lowest priority for me, so expect the GUI to be very basic. Perhaps one could even say not basic but clean and simple.
Skip this section, if you have downloaded a package from Releases page, because the scripts there are already in JavaScript, so it is ready to be used out-of-the-box.
Otherwise, the project scripts sources are in TypeScript (starting with v0.3.0), and so they need to be compiled to JavaScript. For that you'll need to have tsc tool, which is installed with npm, which is installed with Node.js. Yes, we all hate Node.js, but that's the easiest way I know for installing TypeScript compiler:
$ npm install -g typescript@latestThis is the only thing what Node.js is needed for, I promise.
Once you have the tool, compile the sources:
$ cd /path/to/rclone-rc-web-gui
$ tscResulting JavaScript files will be put to ./js folder. After that you can use the GUI.
Before launching the GUI, you need to have your remotes configured in ~/.config/rclone/rclone.conf on the host where you will be running rclone rcd.
The easiest would be to let rclone handle downloading and serving the latest release:
$ rclone rcd --transfers 1 --rc-allow-origin http://localhost:5572 \
--rc-web-gui \
--rc-web-fetch-url https://api.github.com/repos/retifrav/rclone-rc-web-gui/releases/latestIf you have used this functionality before, then you might have a different web GUI already downloaded in your system (for example, on Mac OS it would be here: ~/Library/Caches/rclone/webgui), and to replace it you'll need to add --rc-web-gui-force-update flag.
By default rclone will generate a random password and will also compose a Base64-encoded authentication token for the Authorization header. That token will be also set as an URL query parameter (?login_token=HERE-GOES-THE-VALUE), which is how the code will be able to get it.
The GUI URL will be auto-openned in your web-browser with prepended gui:AUTO-GENERATED-PASSWORD@ for passing through initial authentication prompt, but if you'll stop rclone rcd and launch it again, chances are that your browser (Firefox in my case) will still show the authentication prompt, despite having gui:AUTO-GENERATED-PASSWORD@ in the URL.
In case of launching it on a remote server, you obviously won't get a web-browser auto-openned with provided credentials, so replace --rc-web-gui with --rc-web-gui-no-open-browser in the CLI, and then it will print the URL with credentials to the stdout.
If you'd like to set your own username/password, then you need to explicitly set --rc-user/--rc-pass and edit settings.js in the rclone's cache directory (on Mac OS it would be here: ~/Library/Caches/rclone/webgui/current/build/js/settings.js). But of course those values will be overwritten on the next GUI update.
Or you can just set --rc-no-auth to disable authentication, which is not recommended.
Get a package from Releases page (or build it from sources). Set your rclone rcd host, port, username and password in ./js/settings.js.
Launch rclone rcd and point it to the folder with web GUI:
$ cd /path/to/rclone-rc-web-gui
$ rclone rcd --transfers 1 --rc-user YOUR-USERNAME --rc-pass YOUR-PASSWORD .or:
$ rclone rcd --transfers 1 --rc-user YOUR-USERNAME --rc-pass YOUR-PASSWORD /path/to/web/guiI personally prefer to have only 1 ongoing transfer at a time, hence --transfers 1. Of course, that only applies to directory operations, as daemon allows to span as many operations as you want (for which I implemented the queue functionality).
If you want to serve web GUI files with a web-server, then launch rclone daemon and allow the origin that you'll have with that server:
$ rclone rcd --transfers 1 --rc-user YOUR-USERNAME --rc-pass YOUR-PASSWORD --rc-allow-origin http://127.0.0.1:5572 /path/to/web/guiYou might also want to create a service for running rclone daemon.
If you get 401/403 errors for all/some of the requests, then check that the values you've provided in --rc-user and --rc-pass match the rcloneSettings.user and rcloneSettings.pass values in your settings.js.
If you didn't intend to use authentication, then make sure that you launched rclone rcd with --rc-no-auth flag and that rcloneSettings.user, rcloneSettings.pass (and rcloneSettings.loginToken) are set to null.
In certain situations you might get different origins between server and client, mostly when serving web GUI from a remote host, but that can also happen while testing it on your local host.
If you get:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://127.0.0.1:5572/core/version. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘http://127.0.0.1:5572/’).
or:
Access to XMLHttpRequest at 'http://127.0.0.1:5572/core/version' from origin 'http://127.0.0.1:5572' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'http://127.0.0.1:5572/' that is not equal to the supplied origin.
check if you ran rclone rcd with --rc-allow-origin http://127.0.0.1:5572 option.
Also note that with --rc-web-gui (instead of --rc-web-gui-no-open-browser) provided for rclone rcd it will automatically open the web GUI in browser at http://localhost:5572 location, and that might cause a CORS mismatch. If that happens, then you'll need to either open exactly http://127.0.0.1:5572 (if that is what you've set in --rc-allow-origin) or set rcloneSettings.host to http://localhost:5572 in settings.js.
There are several settings available for you to configure in ./js/settings.js.
Aside from self-explanatory variables like host, credentials and timers, there is an object for storing settings for your remotes. An example:
var remotes = {
"disk": {
"startingFolder": "media/somedisk/downloads",
"canQueryDisk": true,
"pathToQueryDisk": "media/somedisk"
},
"seedbox": {
"startingFolder": "files",
"canQueryDisk": false,
"pathToQueryDisk": ""
}
}Here:
- we have 2 remotes:
diskandseedbox; - both have
startingFolderset, so that will be the folder opened when the remote is chosen in the files panel; diskhascanQueryDiskset totrue, so it supports querying information about available disk space;- in case of external disks, you'll also need to set their mounted path (
pathToQueryDisk).
- in case of external disks, you'll also need to set their mounted path (
All operations go to the queue and processed one at a time.
Obviously, since the queue is implemented on the client side, it's only your browser who knows about it, so if you add more operations from a different host, browser, or even a different tab in the same browser - all of them will go in parallel.
That also means that once you close the browser or just this tab, the queue will no longer exist. However, all the ongoing transfers will of course still be there, as they are already being handled by rclone (_async = true).
There is a Docker image, which might be the easiest way of running/deploying the project. But if you'd prefer to launch/deploy it yourself, read the instructions below.
TLDR:
rclone rcdis run as a systemd service;- NGINX is used as a reverse proxy;
- web GUI is available via custom base URL such as
http://IP-ADDRESS-OR-DOMAIN/rclone/.
Get a package from Releases page (or build it from sources):
$ cd /var/www
$ sudo wget https://github.com/retifrav/rclone-rc-web-gui/releases/latest/download/rclone-rc-web-gui.zip
$ sudo unzip ./rclone-rc-web-gui.zip && sudo rm ./rclone-rc-web-gui.zip
$ sudo mv ./build ./rclone-rc-web-gui
$ sudo chown -R www-data:www-data /var/www/rclone-rc-web-guiCreate a systemd service:
$ sudo nano /etc/systemd/system/rclone-gui.service[Unit]
Description=rclone web GUI
[Service]
WorkingDirectory=/media/
ExecStart=rclone rcd --rc-web-gui-no-open-browser --rc-addr 127.0.0.1:8004 --rc-allow-origin http://IP-ADDRESS-OR-DOMAIN --rc-htpasswd /home/SOME-USER/.htpasswd --transfers 1 --multi-thread-streams 1 /var/www/rclone-rc-web-gui/
Restart=always
RestartSec=10
SyslogIdentifier=rclonewebgui
User=SOME-USER-WITH-REQUIRED-DISK-ACCESS
Group=www-data
[Install]
WantedBy=multi-user.targethere:
http://IP-ADDRESS-OR-DOMAIN- the requests will be coming from the same server, so you need to provide here either the IP address of that server or its domain, if you have one. In my case it's just a server in my local network, so I've set this tohttp://192.168.1.11(static MAC-binded IP address of my server);SOME-USER-WITH-REQUIRED-DISK-ACCESS- a user from whichrclonewill be run, so perhaps it's a good idea to create a new user for this purpose and limit its access to just one folder such as/media/;WorkingDirectory=/media/- if you'll have your local filesystem as one of the rclone's remote too, then/media/would be a starting folder (for me that's where I mount external disks);.htpasswd- a slightly better security, instead of providing credentials in plain text they are stored somewhat encrypted.
Enable and start the service:
$ sudo systemctl enable rclone-gui.service
$ sudo systemctl start rclone-gui.serviceNGINX configuration:
$ sudo nano /etc/nginx/sites-enabled/defaultserver {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
# a "parent" website or some welcome/home page
# that is what will open on http://IP-ADDRESS-OR-DOMAIN/
root /var/www/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
# rclone rc web GUI, will open on http://IP-ADDRESS-OR-DOMAIN/rclone/
location /rclone/ {
proxy_pass http://localhost:8004/;
}
}$ sudo systemctl restart nginx.serviceSet the credentials (the same ones that are in /home/SOME-USER/.htpasswd) and adjust the host value:
$ sudo -u www-data nano /var/www/rclone-rc-web-gui/js/settings.jsvar rcloneHost = "http://IP-ADDRESS-OR-DOMAIN/rclone"; // using port 80, so no need to set it
var rcloneUser = "USERNAME-FROM-HTPASSWD";
var rclonePass = "PASSWORD-FROM-HTPASSWD";Add some remotes to rclone config, if you haven't yet:
$ rclone configNow you should be able to access the web GUI on http://IP-ADDRESS-OR-DOMAIN/rclone/.
I've created this project mostly for myself. So it's better to state right away that there is basically no support and that I am not responsible for any possible data loss you might get from using this project. In fact, I don't recommend you to rely on it for anything important, and certainly don't use it on servers with valuable data.
Also note, that since I use Mozilla Firefox as my main web-browser, that's where I did all the testing, and I've spent very little to none effort on maintaining cross-browser-ability.
If you discover any issues/bugs, report them here.
The project doesn't use any external libraries/frameworks, it's just plain HTML/CSS/JS. Well actually, now it's not JavaScript but TypeScript, so there is a requirement to have tsc tool for compiling TypeScript sources to JavaScript.
- icons are from Bootstrap Icons
- favicon is from rclone website