New Release: Vault Phase 1 (real vault)

I don’t see your public name on shared vault, you must have been storing it in your own local vault I guess, and that’s why you cannot fetch the song file or safe://test.

You need to make sure you place the vault_connection_info.config in the right place as detailed in the OP, and then have your safe_auth restarted so it connects to shared vault to login and/or create an account, then you should authorise your safe_cli so it then connects to the shared vault also.

There was an issue with packaging the browser unfortunately, we are investigating and trying to solve it ASAP, in the meanwhile you can build it from source code from this branch, yarn and then launch it with yarn start


I guessed this might be the problem so I have copied it again and repeated the steps a couple of times. It looks like I’m still using a local vault but I’m not sure why.

I’ll go again starting with downloading it afresh! Thanks Gabriel.


Ok @happybeing , you can run safe --version to make sure you have v0.2.2, same for safe_auth --version and it should show v0.2.0. Perhaps the issue you have is that you are still running your local vault? I can see safe_auth will find it first before trying with shared vault, so probably make sure you stop your local vault?


I have:

$ safe --version
safe_cli 0.2.2

$ safe_auth --version
safe_auth 0.1.0 <- not 0.2.0

Both downloaded today from the links in last night’s post and it is definitely the version extracted from the archive safe_authenticator_cli-0.2.0-x86_64-unknown-linux-gnu.tar. I just checked.

I only have the one vault running, so not an earlier local vault.

Now doing safe_auth --update

That’s odd, even after update things are still not working and safe_auth --version still reports v0.1.0!

NOTE: One possibility is that other people already had the binaries and that --update worked, but I hadn’t downloaded any of these previously so have the version in the archive, and it seems not to update even though it says it will!


I have the same problem.


Right @happybeing @Sascha, we just spotted a bug then in the version reported by the safe_auth binary. I’ll raise it so we can fix it for next release.

@happybeing I think we can ignore the issue with the wrong version reported by the binary, you should be fine to use it. Not sure if I follow you, what I meant was that to connect to the shared vault you make sure you don’t run any local vault. I tried it and if you have a local vault running, even with the config file in place, the safe_auth seems to first connect to you local one. So can you try stopping/killing any/all your local vaults and then try to use the CLI to connect to shared vault?


Thanks Gabriel, I misunderstood. I was getting a timeout when I tried without first running safe_vault so I thought the idea was to run the vault but with the alternative config.

This timeout still happened after you suggested I make sure I wasn’t running a local vault so I’m still having problems. I’m not sure if I’d updated before that but think I had. Will have to check later.

What is using the ~/.config/safe_vault/blah.config when using the shared vault if it isn’t safe_vault?


I guess the config file name can be misleading/confusing you, but the safe_auth (actually the SCL library) will use it to connect to the shared vault. Likewise, the browser would use it to connect to shared vault.

Also, the shared vault is a vault like the one we are all running locally, it’s just one that is running on a server so people can connect to it instead of running a local one. In fact I believe anyone can run a local vault, and share the config file with its public IP to others to connect to it with CLIs and browser.


I had the same problem. When you run the local vault, it creates the config file … and blows away the other config file that you downloaded from github that allows connecting to shared vault.

Overwrite the config file that the local vault created, with the one from github … and then never run the local vault again to avoid overwriting it again.


I am up and running to the shared vault on the same Windows 10 computer I struggled with yesterday on local vault. Local vault still not working, but shared vaults working great.

Here’s my contribution to the shared vault.

safe cat safe://hbyyyydumbcdx4yd55q4bg3yxfjkrw15rbepchpy5izded53useofe5fge > maidsafe.mp4


I suspect this is the answer! Thanks Tom. Confirmed - my running safe_vault was overwriting the vault config and forcing connection to local vote or a timeout when the safe_vault wasn’t running.

@Maidsafe I suggest the OP is clarified to say that to use the shared vault, do NOT run safe_vault and always copy the shared config, because every time you run safe_vault it resets the config to look for a locally running safe_vault.


I can’t get
$ safe_auth --apps
to work. Am I doing something completely idiotic?


sascha@Knut-Mint:/mnt/Data/SAFE$ ./safe cat safe://hbyyyydumbcdx4yd55q4bg3yxfjkrw15rbepchpy5izded53useofe5fge > maidsafe.mp4
[2019-08-30T18:44:46Z ERROR safe] safe_cli error: [Error] NetDataError - Failed to GET Published ImmutableData: CoreError(No such data - CoreError::DataError -> NoSuchData)
1 Like

Fragment of new Cyberpunk 2077 – Deep Dive Video:

safe cat safe://cyberpunk/banhammer.mp4 > banhammer.mp4

1 Like

I wonder if safe_vault overwriting the config automatically is wise. It could ask first, or perhaps better an option could be provided to allow or prevent overwriting the config. Thoughts @bochaco?


I think it should, however we should probably add flags to clients if you want to use connection info for connecting to other vaults than locally running one


I’m not sure how to use safe_auth --apps either. I have the daemon running already and the following just hangs but possibly you aren’t supposed to run safe_auth more than once?

safe_auth --apps
Logged in the SAFE Network successfully!

I created a Ubuntu VM with Hyper-V on Windows 10 but I cannot make it work. I am new to Ubuntu Desktop, so this may be a basic usage error.

When I double click on safe-browser icon I get this error:


And in a terminal:


Beat you to it here :wink:. It’s a build bug, see:


For those who want to get up and running on the shared vault as fast as possible, here’s what I did (but I did not do this fast…)

Get binary files and config file

  • Download safe_vault, safe, and safe_auth
  • Run safe_vault - it will tell you it’s making a config file. Make a note of where it says it’s putting it.
  • Now, overwrite that config file it just made with this one, and never run safe_vault again (If you want to use the shared vault)

Create a new account with some secret and password that you will make up

  • safe_auth --test-coins

Start your daemon with the same secret and password that you used to create account

  • safe_auth --daemon 41805
  • this command window cannot be closed now, so open a new one for the rest

Authorize your CLI

  • safe auth
  • Go back to your other, open command window, where your daemon is running, and hit ‘y’ to authorize

Upload a directory and all it’s contents into the shared vault. Make a note of the hashes for each file

  • safe files put .your_dir_name --recursive

Tell your friends the hashes, so they can read the files

  • safe cat safe://hbyyyydumbcdx4yd55q4bg3yxfjkrw15rbepchpy5izded53useofe5fge > maidsafe.mp4

Also useful:

$ safe files put cyberpunk/ --recursive
FilesContainer created at: "safe://hnyynyzyny5xx5fhp5uyiedbrph3akrw4oeuy4a7fsm9crjjnsawg3jybobnc"
+  cyberpunk/banhammer.mp4 safe://hbyyyydw8ay879ejpdknrbmmig31gxjr9qexxqhe5bq3wsdhd3xwdxaasd
$ safe nrs create cyberpunk --link safe://hnyynyzyny5xx5fhp5uyiedbrph3akrw4oeuy4a7fsm9crjjnsawg3jybobnc?v=0
New NRS Map for "safe://cyberpunk" created at: "safe://hnyydyistmxhjpjw4txtik9187oe5wr3b6kg1qr83hn41dijjtcmuhuoxrbqh"
+  cyberpunk  safe://hnyynyzyny5xx5fhp5uyiedbrph3akrw4oeuy4a7fsm9crjjnsawg3jybobnc?v=0