Mega

At a glance

Capability	Support
rclone support tier	Tier 2: Stable
Checksums	None
Modification times	Not kept: files show their upload time
Case-insensitive names	No
Duplicate names allowed	Yes
Server-side copy	No
Server-side move and rename	Yes
Folder move and rename	Yes, in one step
Free space reporting	Yes
Empty folders	Yes
Change notifications	No
Uploads of unknown size	No
Public links	Yes

From rclone’s documentation

The rest of this page is adapted from rclone’s documentation for this backend (rclone v1.75.2, MIT licence). It is written for rclone’s command line: where it mentions a flag such as --mega-example, set the option example in the wizard’s options instead. Commands such as rclone copy aren’t part of CloudMount.

Mega is a cloud storage and file hosting service known for its security feature where all files are encrypted locally before they are uploaded. This prevents anyone (including employees of Mega) from accessing the files without knowledge of the key used for encryption.

This is an rclone backend for Mega which supports the file transfer features of Mega using the same client side encryption.

Note MEGA S4 Object Storage, an S3 compatible object store, also works with rclone and this is recommended for new projects.

Setup notes

In CloudMount you add this drive from the Add drive screen, and the wizard asks for the options listed under Options. The notes below come from rclone’s setup guide.

Modification times and hashes

Mega does not support modification times or hashes yet.

Restricted filename characters

Character	Value	Replacement
NUL	0x00	␀
/	0x2F	／

Invalid UTF-8 bytes will also be replaced, as they can’t be used in JSON strings.

Duplicated files

Mega can have two files with exactly the same name and path (unlike a normal file system).

Duplicated files cause problems with the syncing and you will see messages in the log about duplicates.

Use rclone dedupe to fix duplicated files.

Failure to log-in

Object not found

If you are connecting to your Mega remote for the first time, to test access and synchronization, you may receive an error such as

Failed to create file system for "my-mega-remote:":
couldn't login: Object (typically, node or user) not found

The diagnostic steps often recommended in the rclone forum start with the MEGAcmd utility. Note that this refers to the official C++ command from https://github.com/meganz/MEGAcmd and not the go language built command from t3rm1n4l/megacmd that is no longer maintained.

Follow the instructions for installing MEGAcmd and try accessing your remote as they recommend. You can establish whether or not you can log in using MEGAcmd, and obtain diagnostic information to help you, and search or work with others in the forum.

MEGA CMD> login me@example.com
Password:
Fetching nodes ...
Loading transfers from local cache
Login complete as me@example.com
me@example.com:/$

Note that some have found issues with passwords containing special characters. If you can not log on with rclone, but MEGAcmd logs on just fine, then consider changing your password temporarily to pure alphanumeric characters, in case that helps.

Repeated commands blocks access

Mega remotes seem to get blocked (reject logins) under “heavy use”. We haven’t worked out the exact blocking rules but it seems to be related to fast paced, successive rclone commands.

For example, executing this command 90 times in a row rclone link remote:file will cause the remote to become “blocked”. This is not an abnormal situation, for example if you wish to get the public links of a directory with hundred of files… After more or less a week, the remote will remote accept rclone logins normally again.

You can mitigate this issue by mounting the remote it with rclone mount. This will log-in when mounting and a log-out when unmounting only. You can also run rclone rcd and then use rclone rc to run the commands over the API to avoid logging in each time.

Rclone does not currently close mega sessions (you can see them in the web interface), however closing the sessions does not solve the issue.

If you space rclone commands by 3 seconds it will avoid blocking the remote. We haven’t identified the exact blocking rules, so perhaps one could execute the command 80 times without waiting and avoid blocking by waiting 3 seconds, then continuing…

Note that this has been observed by trial and error and might not be set in stone.

Other tools seem not to produce this blocking effect, as they use a different working approach (state-based, using sessionIDs instead of log-in) which isn’t compatible with the current stateless rclone approach.

Note that once blocked, the use of other tools (such as megacmd) is not a sure workaround: following megacmd login times have been observed in succession for blocked remote: 7 minutes, 20 min, 30min, 30 min, 30min. Web access looks unaffected though.

Investigation is continuing in relation to workarounds based on timeouts, pacers, retrials and tpslimits - if you discover something relevant, please post on the forum.

So, if rclone was working nicely and suddenly you are unable to log-in and you are sure the user and the password are correct, likely you have got the remote blocked for a while.

Options

Standard options

The wizard asks for these when you add the drive.

user

User name.

Type: string · Required

pass

Password.

NB Input to this must be obscured - see rclone obscure.

Type: string · Required

2fa

The 2FA code of your MEGA account if the account is set up with one

Type: string

Advanced options

The wizard shows these under Advanced options. Most drives work without changing any of them.

debug

Output more debug from Mega.

If this flag is set (along with -vv) it will print further debugging information from the mega backend.

Type: bool · Default: false

hard_delete

Delete files permanently rather than putting them into the trash.

Normally the mega backend will put all deletions into the trash rather than permanently deleting them. If you specify this then rclone will permanently delete objects instead.

Type: bool · Default: false

use_https

Use HTTPS for transfers.

MEGA uses plain text HTTP connections by default. Some ISPs throttle HTTP connections, this causes transfers to become very slow. Enabling this will force MEGA to use HTTPS for all transfers. HTTPS is normally not necessary since all data is already encrypted anyway. Enabling it will increase CPU usage and add network overhead.

Type: bool · Default: false

encoding

The encoding for the backend.

See the encoding section in the overview for more info.

Type: Encoding · Default: Slash,InvalidUtf8,Dot

description

Description of the remote.

Type: string

Process killed

On accounts with large files or something else, memory usage can significantly increase when executing list/sync instructions. When running on cloud providers (like AWS with EC2), check if the instance type has sufficient memory/CPU to execute the commands. Use the resource monitoring tools to inspect after sending the commands. Look at this issue.

Limitations

This backend uses the go-mega go library which is an opensource go library implementing the Mega API. There doesn’t appear to be any documentation for the mega protocol beyond the mega C++ SDK source code so there are likely quite a few errors still remaining in this library.

Mega allows duplicate files which may confuse rclone.