meganz / MEGAcmd

Command Line Interactive and Scriptable Application to access MEGA
Other
1.95k stars 407 forks source link

mega-login to folder fails on synology #367

Open meeotch opened 4 years ago

meeotch commented 4 years ago

I've just installed megacmd on my synology NAS, and on my ubuntu 18.04 machine. I'm able to login using mega-login on the ubuntu install, but it fails on synology with "Failed to Login: Invalid argument".

Debug log from synology doesn't appear to have anything interesting in it - see below. Logging in with email/pass also fails on synology. Any thoughts for debugging further?

[API:debug: 16:45:50] cURL version: 7.49.1
[API:debug: 16:45:50] SSL version: OpenSSL/1.0.2h
[API:debug: 16:45:50] libz version: 1.2.8
[API:debug: 16:45:50] IPv6 enabled: 1
[API:debug: 16:45:50] Initializing OpenSSL locking callbacks
[API:debug: 16:45:50] DNS servers: 192.168.0.1
[API:debug: 16:45:50] MediaInfo version: 1710
[API:debug: 16:45:50] User-Agent: MEGAcmd-QNAP/1.0.0.0 (Linux 3.10.105 armv7l) MegaClient/3.4.1
[API:debug: 16:45:50] Cryptopp version: 565
[API:debug: 16:45:50] cURL version: 7.49.1
[API:debug: 16:45:50] SSL version: OpenSSL/1.0.2h
[API:debug: 16:45:50] libz version: 1.2.8
[API:debug: 16:45:50] IPv6 enabled: 1
[API:debug: 16:45:50] DNS servers: 192.168.0.1
[API:debug: 16:45:50] MediaInfo version: 1710
[API:debug: 16:45:50] User-Agent: MEGAcmd-QNAP/1.0.0.0 (Linux 3.10.105 armv7l) MegaClient/3.4.1
[API:debug: 16:45:50] Cryptopp version: 565
[API:debug: 16:45:50] cURL version: 7.49.1
[API:debug: 16:45:50] SSL version: OpenSSL/1.0.2h
[API:debug: 16:45:50] libz version: 1.2.8
[API:debug: 16:45:50] IPv6 enabled: 1
[API:debug: 16:45:50] DNS servers: 192.168.0.1
[API:debug: 16:45:50] MediaInfo version: 1710
[API:debug: 16:45:50] User-Agent: MEGAcmd-QNAP/1.0.0.0 (Linux 3.10.105 armv7l) MegaClient/3.4.1
[API:debug: 16:45:50] Cryptopp version: 565
[API:debug: 16:45:50] cURL version: 7.49.1
[API:debug: 16:45:50] SSL version: OpenSSL/1.0.2h
[API:debug: 16:45:50] libz version: 1.2.8
[API:debug: 16:45:50] IPv6 enabled: 1
[API:debug: 16:45:50] DNS servers: 192.168.0.1
[API:debug: 16:45:50] MediaInfo version: 1710
[API:debug: 16:45:50] User-Agent: MEGAcmd-QNAP/1.0.0.0 (Linux 3.10.105 armv7l) MegaClient/3.4.1
[API:debug: 16:45:50] Cryptopp version: 565
[API:debug: 16:45:50] cURL version: 7.49.1
[API:debug: 16:45:50] SSL version: OpenSSL/1.0.2h
[API:debug: 16:45:50] libz version: 1.2.8
[API:debug: 16:45:50] IPv6 enabled: 1
[API:debug: 16:45:50] DNS servers: 192.168.0.1
[API:debug: 16:45:50] MediaInfo version: 1710
[API:debug: 16:45:50] User-Agent: MEGAcmd-QNAP/1.0.0.0 (Linux 3.10.105 armv7l) MegaClient/3.4.1
[API:debug: 16:45:50] Cryptopp version: 565
[API:debug: 16:45:50] cURL version: 7.49.1
[API:debug: 16:45:50] SSL version: OpenSSL/1.0.2h
[API:debug: 16:45:50] libz version: 1.2.8
[API:debug: 16:45:50] IPv6 enabled: 1
[API:debug: 16:45:50] DNS servers: 192.168.0.1
[API:debug: 16:45:50] MediaInfo version: 1710
[API:debug: 16:45:50] User-Agent: MEGAcmd-QNAP/1.0.0.0 (Linux 3.10.105 armv7l) MegaClient/3.4.1
[API:debug: 16:45:50] Cryptopp version: 565
[debug: 16:45:50] Language set to:
[debug: 16:45:50] CREATING sockets folder: /tmp/megaCMD_1026!!!

.===================================================================================================================.
|                                   __  __ _____ ____    _                      _                                   |
|                                  |  \/  | ___|/ ___|  / \   ___ _ __ ___   __| |                                  |
|                                  | |\/| | \  / |  _  / _ \ / __| '_ ` _ \ / _` |                                  |
|                                  | |  | | /__\ |_| |/ ___ \ (__| | | | | | (_| |                                  |
|                                  |_|  |_|____|\____/_/   \_\___|_| |_| |_|\__,_|                                  |
|                                                                                                                   |
|                                                      SERVER                                                       |
`===================================================================================================================´
[info: 16:45:50] Listening to petitions ...

[API:info: 16:47:13] Request (LOGIN) starting
[API:debug: 16:47:13] Reinitializing the network layer
[API:debug: 16:47:13] DNS servers: 192.168.0.1
[API:err: 16:47:13] Error starting request: -2
[API:warn: 16:47:13] Request (LOGIN) finished with error: Invalid argument
[debug: 16:47:13] actUponLogin login
[debug: 16:47:13] actUponLogin login email: FOLDER
[err: 16:47:13] Failed to Login: Invalid argument
meeotch commented 4 years ago

Quick update: I got mega-login to work with email/pass (needed to change my password to one that didn't start with a special character). However logging in with a folder link still fails with "invalid argument". Unfortunately, I need a non-password method of logging in, since I don't want to leave my credentials lying around in a script on a remote machine.

mega-get seems to fail on synology with the same error, in fact:

[API:info: 18:01:15] Request (GET_PUBLIC_NODE) starting
[API:err: 18:01:15] Error starting request: -2
[API:warn: 18:01:15] Request (GET_PUBLIC_NODE) finished with error: Invalid argument
[err: 18:01:15] Failed to get public node: Invalid argument
[err: 18:01:15] The link provided might be incorrect: https://mega.nz/folder/<id#key>
polmr commented 4 years ago

Note on links: https://github.com/meganz/MEGAcmd/issues/343 . Regarding the login, MEGAcmd keeps a session working from restarts until logout. You can also login with a session which can be retrieved via session and also logout without closing a session (for you to reuse, instead of login with user/pass). More info: mega-login --help (login --help from MEGAcmd shell), session --help & logout --help. I hope that serves you. Anyway, ideas for improvement are very welcomed.

meeotch commented 4 years ago

Brilliant - translating the folder link worked, thanks!

Regarding sessions - the docs say that they are resumed, in the case that the client machine reboots and has to restart the megacmd server. Does this mean that a session ID is more along the lines of a public key, in terms of robustness? There's nothing that will cause a session to die or expire, except explicitly killing it?

I think the one feature that sessions don't have that I'd prefer is the ability to "jail" them to a specific directory root. It feels like a folder login is more appropriate for my situation, where I want the client machine to only have access to part of my mega account.