Access denied at 'files put'

  • OS: Manjaro Linux
  • Safe apps
    • safe-auth: 0.15.0
    • safe-cli: 0.15.0
    • safe-vault: 0.15.0

I haven’t used the safenet network in a while again (a year?) and I have to say it’s looking a lot better than last time with all the files put in ~/.safe these days.

But I can’t seem to add files at the moment.

> files put ./dist/ --recursive
[Error] NetDataError - Failed to store Public Sequence data: Data error -> Access denied - CoreError::DataError -> AccessDenied

Does any know what I’m doing wrong?

I am logged in.

> auth status
Sending request to authd to obtain a status report...
+------------------------------------------+--------+
| SAFE Authenticator status                |        |
+------------------------------------------+--------+
| Authenticator daemon version             | 0.0.11 |
+------------------------------------------+--------+
| Logged in to a SAFE account?             | Yes    |
+------------------------------------------+--------+
| Number of pending authorisation requests | 0      |
+------------------------------------------+--------+
| Number of notifications subscribers      | 0      |
+------------------------------------------+--------+
1 Like

Are you using a local test network with:

safe vault run-baby-fleming

If not, see: https://github.com/maidsafe/safe-api/tree/master/safe-cli#run-a-local-network

If you are I don’t know what the problem might be.

Is there a way to check whether or not the vault is running?

You can search for the vault process on your OS. If you can provide more info it will be easier to help.

Looks like they’re running.

ps -ef | grep vault

folaht      9154       1  9 14:11 pts/1    00:00:32 /home/folaht/.safe/vault/safe_vault -vv --local --first --root-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-genesis --log-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-genesis
folaht      9161       1  9 14:11 pts/1    00:00:31 /home/folaht/.safe/vault/safe_vault -vv --local --hard-coded-contacts ["127.0.0.1:47852"] --root-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-2 --log-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-2
folaht      9165       1 10 14:11 pts/1    00:00:32 /home/folaht/.safe/vault/safe_vault -vv --local --hard-coded-contacts ["127.0.0.1:47852"] --root-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-3 --log-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-3
folaht      9169       1 10 14:11 pts/1    00:00:34 /home/folaht/.safe/vault/safe_vault -vv --local --hard-coded-contacts ["127.0.0.1:47852"] --root-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-4 --log-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-4
folaht      9173       1  0 14:11 pts/1    00:00:01 /home/folaht/.safe/vault/safe_vault -vv --local --hard-coded-contacts ["127.0.0.1:47852"] --root-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-5 --log-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-5
folaht      9177       1  8 14:11 pts/1    00:00:27 /home/folaht/.safe/vault/safe_vault -vv --local --hard-coded-contacts ["127.0.0.1:47852"] --root-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-6 --log-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-6
folaht      9186       1 38 14:11 pts/1    00:02:01 /home/folaht/.safe/vault/safe_vault -vv --local --hard-coded-contacts ["127.0.0.1:47852"] --root-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-7 --log-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-7
folaht      9190       1 20 14:11 pts/1    00:01:04 /home/folaht/.safe/vault/safe_vault -vv --local --hard-coded-contacts ["127.0.0.1:47852"] --root-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-8 --log-dir /home/folaht/.safe/vault/baby-fleming-vaults/safe-vault-8

I just tried this and got the same error so I’m not sure what the problem is but I assume there’s been a change to the released software which has broken something.

It should be possible to build an earlier version and use that. It may be simpler to wait for the next working update but I don’t know when that will be as they have been making widespread changes recently.

By the way, you can check the individual vault logfiles:

ls ~/.safe/vault/baby-fleming-vaults/*/safe_vault.log

Well it seems like I had not switched to the shared-section?
Because right now, I’m not able to login anymore either.

safe auth login
Passphrase: 
Password: 
Sending login action request to authd...
[2020-09-07T12:35:16Z ERROR safe] safe-cli error: [Error] AuthdError - [Error] AuthError - Failed to log in: Core error: Unexpected: Connection timed out when bootstrapping to the network

You must either run a local test (safe vault run-baby-fleming) or join the shared section test, but the latter is not running so that is not an option at the moment.

You mean to say that there’s no shared community network at the moment?
Aren’t there at least a dozen people here currently testing this thing?

Not that I’m aware.

Just to be clear, there were many! Everyone is still here as well but there have been some big changes such as the removal of PARSEC for BLS-DKG, CRDT data types and tree data type, addition of Asynchronous Trustworthy Transfers and small bits of farming. A LOT has changed since even the last test net that was only a couple months ago. So the reason no one would be testing rn is just in anticipation for the upcoming changes.

1 Like

@folaht you just need to make sue your CLI is authorise with write access, try to login again but with this additional flag:

$ safe auth login --self-auth

We plan to improve the Access Denied error message to suggest this same solution. Once you authorised the CLI try to upload the files to your local network again.

2 Likes

Is that correct when using local vaults?

Checking back to when I last did this my notes say I was doing:

safe vault run-baby-fleming
safe files put --recursive ~/.syncer-test/

I thought I needed -t as well, so may have forgotten to note that but it doesn’t look like I also needed to auth before the safe files put.

Yes, a local network is the same as a shared one, the only difference it’s that we run the shared section/network on the cloud with public IPs for people to join/connect-to. Thus, you need write access for your apps like CLI.

1 Like

This doesn’t appear to be needed when using -t. I was confused because I got the same error as @folaht earlier, but I can’t reproduce that error now.

@folaht, try the following. It’s working for me at the moment:

safe vault killall
RUST_LOG=info,quinn=error safe vault run-baby-fleming -t

In the log output I get:

[2020-09-07T16:07:43Z INFO  safe_api::api::authd_client::authd_client_api] SAFE login action was successful: Logged in successfully!
Logged in successfully

So using -t is both creating the account and logging the safe cli in.

This is confirmed by then doing:

$ safe auth status
Sending request to authd to obtain a status report...
+------------------------------------------+--------+
| SAFE Authenticator status                |        |
+------------------------------------------+--------+
| Authenticator daemon version             | 0.0.11 |
+------------------------------------------+--------+
| Logged in to a SAFE account?             | Yes    |
+------------------------------------------+--------+
| Number of pending authorisation requests | 0      |
+------------------------------------------+--------+
| Number of notifications subscribers      | 0      |
+------------------------------------------+--------+

Put a single file works:

$ echo test > junk.txt
$ safe files put junk.txt
FilesContainer created at: "safe://hnyynyqs7hoqkndrtbiwfgztpn8uxqowu4o1jfjsix3yeooeg8ctuk3omgbnc"
+  junk.txt  safe://hbhydyda6qp75zybw7rcnpxuxebwbqfrakjbnkyrf17mus71cnigp51r1e 

Put a directory containing two files:

$ safe files put -r junk/
FilesContainer created at: "safe://hnyynyxw5p5ewjhkubkf9mmixbgtoqdgjau8zec5m614rbayarot64ku6sbnc"
+  junk/netstat.txt  safe://hbhydynyzp5e9b8wdd3eoi95be4u68t4poxbbjzok6gqwtad78epfwy6m6 
+  junk/test.txt     safe://hbhydyda6qp75zybw7rcnpxuxebwbqfrakjbnkyrf17mus71cnigp51r1e
2 Likes

This topic was automatically closed after 60 days. New replies are no longer allowed.