I am trying to add a remote for SMB/CIFS according to the documentation, but I am not seeing an option for it in the list of protocols after running rclone config.
Current remotes:
Name Type
==== ====
drive drive
e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q> n
Enter name for new remote.
name> remote
Option Storage.
Type of storage to configure.
Choose a number from below, or type in your own value.
1 / 1Fichier
\ (fichier)
2 / Akamai NetStorage
\ (netstorage)
3 / Alias for an existing remote
\ (alias)
4 / Amazon Drive
\ (amazon cloud drive)
5 / Amazon S3 Compliant Storage Providers including AWS, Alibaba, Ceph, China Mobile, Cloudflare, ArvanCloud, Digital Ocean, Dreamhost, Huawei OBS, IBM COS, IDrive e2, Lyve Cloud, Minio, Netease, RackCorp, Scaleway, SeaweedFS, StackPath, Storj, Tencent COS and Wasabi
\ (s3)
6 / Backblaze B2
\ (b2)
7 / Better checksums for other remotes
\ (hasher)
8 / Box
\ (box)
9 / Cache a remote
\ (cache)
10 / Citrix Sharefile
\ (sharefile)
11 / Combine several remotes into one
\ (combine)
12 / Compress a remote
\ (compress)
13 / Dropbox
\ (dropbox)
14 / Encrypt/Decrypt a remote
\ (crypt)
15 / Enterprise File Fabric
\ (filefabric)
16 / FTP
\ (ftp)
17 / Google Cloud Storage (this is not Google Drive)
\ (google cloud storage)
18 / Google Drive
\ (drive)
19 / Google Photos
\ (google photos)
20 / HTTP
\ (http)
21 / Hadoop distributed file system
\ (hdfs)
22 / HiDrive
\ (hidrive)
23 / Hubic
\ (hubic)
24 / In memory object storage system.
\ (memory)
25 / Internet Archive
\ (internetarchive)
26 / Jottacloud
\ (jottacloud)
27 / Koofr, Digi Storage and other Koofr-compatible storage providers
\ (koofr)
28 / Local Disk
\ (local)
29 / Mail.ru Cloud
\ (mailru)
30 / Mega
\ (mega)
31 / Microsoft Azure Blob Storage
\ (azureblob)
32 / Microsoft OneDrive
\ (onedrive)
33 / OpenDrive
\ (opendrive)
34 / OpenStack Swift (Rackspace Cloud Files, Memset Memstore, OVH)
\ (swift)
35 / Pcloud
\ (pcloud)
36 / Put.io
\ (putio)
37 / QingCloud Object Storage
\ (qingstor)
38 / SSH/SFTP
\ (sftp)
39 / Sia Decentralized Cloud
\ (sia)
40 / Storj Decentralized Cloud Storage
\ (storj)
41 / Sugarsync
\ (sugarsync)
42 / Transparently chunk/split large files
\ (chunker)
43 / Union merges the contents of several upstream fs
\ (union)
44 / Uptobox
\ (uptobox)
45 / WebDAV
\ (webdav)
46 / Yandex Disk
\ (yandex)
47 / Zoho
\ (zoho)
48 / premiumize.me
\ (premiumizeme)
49 / seafile
\ (seafile)
Storage>
Additional notes
I see in the documentation the following note:
This relies on go-smb2 library for communication with SMB protocol.
Is this saying I need to fetch this library if I want to have the option of choosing SMB/CIFS as a backend? Or is this just a technical detail about how Rclone integrates with SMB/CIFS?
I can confirm after running rclone selfupdate and verifying version 1.60.0 that I now see the option for SMB/CIFS.
If I could make a recommendation though: In the documentation for each feature, maybe there could be a note on the sidebar about the first release version? That way people can see which version they need to be on to use a feature?
Of course, if people are following the release schedule and updating frequently, maybe this is a moot point.
That's very tough to maintain and would be documentation hell imo.
We do ask for checking the versions as part of the template so I wonder if there is better wording?
Do not type in "Latest".
Do not just type in a version number. Run the command and share the full output.
Are you on the latest version of rclone? You can validate by checking the version listed here: https://rclone.org/downloads/
Did you end up checking that or would have some better wording maybe?
@Animosity022 Thanks for explaining. I understand why you might not want to take that on.
I am new to the Rclone project and did not realize how quickly it changes. So admittedly, I assumed I was on the latest version since I just installed it a couple months ago. But I see now that a minor and major revision were made in that time.
I think your explanation in the template is good enough, I just need to read a little more carefully next time.
Yes. I was thinking about adding something to the header of each of the backend pages which showed the version or rclone that the backend was introduced.
It would be easy to get the templates to render that somewhere so all backend authors would have to do is set the version flag. Maybe I'd call it versionIntroduced.
---
title: "Google drive"
description: "Rclone docs for Google drive"
version: 1.32
---
Is it worth doing?
How do you think the versionIntroduced should show on the page? Maybe as a grey box floating next to the title?
Sounds like there's a consensus, but for the record, this is what I was thinking: Just a "version introduced" for each backend. Definitely not advocating for bumping version on documents for 50+ backends every time there's a minor upgrade.
I see your point, but I think it will probably look a bit verbose - at least on a small phone screen it might not look so good. There is extended description in tooltips, e.g. "This feature needs Rclone v1.60.0 or later.", but then again - on a phone/touch device tooltips are usually not that accessible...
I think they are too verbose like that. I think just Experimental and v1.60.0 is fine. If we wanted to make them accessible on a phone then we could make clicking on them produce the tooltip. I'm sure there is a bootstrap thingy for that!
