Huh I’m logged in… It’s probably this
I’ll try again tomorrow sober, cheers mate
You need to login but authorise CLI as well, otherwise CLI doesn’t have permissions from your account to write on the network, just self-authorise CLI with $ safe auth login --self-auth
and you should be fine.
Nice work Maidsafe team! So far I could join the network without problems and also saw some incoming requests for storing Immutable data chunks.
However since this release I’m not able anymore to run “safe auth start” and therefore can’t interact with the network. After entering the start command it just keeps hanging and does nothing. I’ve already tried “safe auth stop” and “safe auth restart” but still no success. Even restarted the PC. I’m using Win 10 with PowerShell. I ran all update commands. @bochaco any idea what I might be missing? Can I somehow see if the process is still running or anything? The task manager doesn’t show anything as far as I can see.
After you did $ safe auth start
, are you able to get any response with $ safe auth status
? can you check if there is anything useful written to the log file at C:\Users\<user>\.safe\authd\logs\safe-authd.log
?
After I run safe auth start
it keeps hanging until I forcefully stop the command with CTRL + C. Here is the cmd output:
.\safe.exe auth start
[2020-07-16T20:18:03Z DEBUG safe] Starting SAFE CLI…
[2020-07-16T20:18:03Z DEBUG safe::cli] Processing command: CmdArgs { cmd: Some(Auth { cmd: Some(Start { authd_path: None }) }), output_fmt: None, output_json: false, dry: false, xorurl_base: None, endpoint: None }
[2020-07-16T20:18:03Z DEBUG safe_api::api::authd_client::authd_client_api] Creating new authd client for endpoint https://localhost:33000
[2020-07-16T20:18:03Z DEBUG safe_api::api::authd_client::authd_client_api] Attempting to start authd from ‘C:\Users\Alexander.safe\authd\safe-authd.exe’ …
and here the corresponding log file:
INFO 2020-07-16T22:18:03.345701200+02:00 [safe-authd\operations.rs:145] Running authd instance from executable at “C:\Users\Alexander.safe\authd\safe-authd.exe”
INFO 2020-07-16T22:18:03.345701200+02:00 [safe-authd\operations.rs:151] authd instance starting (PID: 13968)…
DEBUG 2020-07-16T22:18:03.345701200+02:00 [safe-authd\operations.rs:154] PID file to be written at: “C:\Users\Alexander\.safe\authd\logs\safe-authd.pid”
INFO 2020-07-16T22:18:03.345701200+02:00 [safe-authd\operations.rs:179] Initialising SAFE Authenticator services…
INFO 2020-07-16T22:18:03.350687800+02:00 [safe-authd\authd.rs:80] Listening on [::1]:33000
Perhaps it’s then running correctly and just the CLI not returning the control. Can you try loging in from another console? i.e. keep that one running without pressing ctrl+c and login with CLI from a second console
Ah yeah of course! Thanks, that worked. I guess I was just too excited because of the successful vaults from home test.
Good, but that’s a bug then, you shouldn’t need to open another console and authd should run in the background, I’ll try to reproduce it in the next few days and fix it. Windows always gives us some fun work
How would the network react if I opened and edited the content of one of these files?
I’m guessing it would identify it is corrupt and replace it?
01000000f5b91269e7229159c6916606b67c78309ae5481d2c93b8e5712b451830eb9fde
01000000b6413999ff9b126b5cfe77790dc1fb3df73eae0238e173466879c36105d4e514 01000000f6876da2c5346c4d345c8c8fb07094b5e0da42f538062fa805008f74635d8c9c
Good to know! I think in the previous releases it worked without opening a new console, so I guess that’s why I was confused. I use Win 10 Pro V 1903 OS build 18362.959 PowerShell Version 5.1.18362.752
Hope that helps.
congratulations on so much hard work done - with success!!
I think we should perhaps indicate this in the cli screen or every operation perhaps. Great feedback though from the community as ever.
And possibly kill your vault, not yet though
Yes, we can probably catch any AcccessDenied
error from CLI and give the hint about authorising the app.
I didn’t try running a vault since my router didn’t work on the last test. But I did try some file upload and download tests.
Time to upload various file sizes (in seconds)
Test | 1K | 900K | 5M |
---|---|---|---|
1 | 3.344 | 11.404 | 36.414 |
2 | 3.437 | 72.426 | 44.263 |
3 | 3.593 | 11.846 | 42.984 |
4 | 3.558 | 11.573 | 43.234 |
5 | 3.304 | 11.781 | 69.693 |
Time to download (only 1 test of each size)
1K: 2.575s
900K: 12.887s
5M: 57.364s
The AccessDenied error would benefit a lot from a hint. This is the error:
$ safe files put /tmp/1k.dat
[2020-07-16T23:47:28Z ERROR safe] safe-cli error: [Error] NetDataError - Failed to store Public Sequence data: Data error -> Access denied - CoreError::DataError -> AccessDenied
A hint such as Try logging in with "safe auth login --self-auth"
would be really helpful as a suggestion for how to solve this problem.
Help could do with some extra info, I really struggled to work out how to upload files.
This command would benefit from listing the --self-auth
flag.
$ safe auth login help
error: Found argument 'help' which wasn't expected, or isn't valid in this context
USAGE:
safe auth login [FLAGS] [OPTIONS]
For more information try --help
This line in the help would benefit from mentioning the --self-auth
flag
$ safe auth help
...
login Send request to a remote Authenticator daemon to log in to a SAFE account
...
I am guessing I jut did not notice before but my chunks are showing up as types: image, html/text or binary. Has this always been the case?
Your script worked perfectly. This is my first participation in a test net! Thanks! So cool!
Is there a compatible safe browser yet?
Not yet. We got the js libs built last night, so I’m updating various browser bits and trying to fix some broken CI this morning, then hopefully we’re good there
Honestly not sure. I’d guess eg small images (<1meg) are one chunk so you have the whole file and your comp can infer even w/o the extension there.
I know chunk obfuscation is not in place yet, so this isn’t entirely unexpected. But it will not be so for release!
UPDATE:
I’d like to thank everyone for their active participation in this testnet. Around 06:00 GMT the vault processes ran out of memory and were killed by the operating system. We will look into this and start another testnet in the near future.