Notification about passphrase

[valdb]

I am getting a notification everytime I access my bucket from the Web UI that i have another 16 objects locked with another passphrase.

Obviously this is some kind of a bug, because i store my passphrase in a text document on my pc and I copy paste it (correctly everytime). I deleted the bucket and the passphrase I uploaded only 4 files and I again I get this message.

Any idea why? sorry for my english.

[Stob]

Hi @valdb
I’m not sure I can recreate the error you mention. When viewing a bucket if there is a number shown for files it is correct for me:

However if it’s just on login when you type a passphrase initially this seems like a generic warning for ‘all’ your buckets, as some of my buckets only have a single passphrase whereas others have multiple:

[valdb]

I have not uploaded other files. Its a new bucket and still I get this message. The only files I have uploaded are visible with my passphrase in My documentaries folder, still I get this notification.

[Knowledge]

I believe this is a bug that will be fixed soon, there is some talk about it in this thread…

[Requesting Feedback] New Encryption Passphrase Workflow

When you first sign up, the box says that each bucket should have its own passphrase but then when you create a new one it doesn’t ask you for a new passphrase. So I’d think the wording needs to change on the new user 1-2-3 step boxes to reflect the new concepts. You could also put on that 1-2-3 step process that if you want to change the passphrase, you can via the project menu dropdown, but if I had to guess independently it’d be in the “access” section under bucket default passphrase or some…

[Alexey]

It also possible, that you really have objects, encrypted with a different encryption phrase.
It’s easy to check:

1. Create an access grant using your current encryption phrase.
2. Setup an Uplink CLI using this access grant.

List all objects in the bucket:

uplink ls --recursive sj://my-bucket

Then list it in the encrypted form:

uplink ls --recursive --encrypted sj://my-bucket

If the number of objects from the first command doesn’t match the number of encrypted objects in the bucket, then you have used a different encryption phrase to upload some of your objects.

[Dragomir-Ivanov]

Greetings,
Coming late to the party, but I also experience this on my fresh account.
Always using default pass phrase creating buckets. Uploading files via same rclone command from a bash script. Leaving a bucket for a while, and “Objects locked” appears in one of my buckets. Can’t unlock with the passphrase.

Having 2 buckets, I have Objects locked in only one.

[arrogantrabbit]

Have a look at this thread Deleted files appear as locked objects - #14 by TowerBR

[Dragomir-Ivanov]

Thank you @arrogantrabbit for your response.
Makes sense. I did removed files only from the bucket that show these “Object locked”.

All the best,
Dragomir

[Alexey]

Hello @Dragomir-Ivanov,
It is a visual effect, the reported usage is appearing with a delay, but the UI detects a difference between settled amount of objects and actual amount of objects, so it concludes that there is some objects encrypted with a different encryption phrase.
I believe it should be fixed already

Folders/Files Appear via Rclone but not via web with Storj

If these numbers are different - then you have objects not decryptable with the current encryption phrase. The command with the --encrypted option returns the same number. I use the same passphrase. I reported this bug here: Storj Web doesn't show some files even with a corrected passphrase · Issue #6370 · storj/storj · GitHub

[Dragomir-Ivanov]

Greetings @Alexey ,
Still seeing “Objects locked” in the bucket in question. However now when I am entering the pass phrase it gives me a warning window, that not all files in that bucket can be decrypted with the supplied pass phrase. I gave me a small heart attack

[Alexey]

This is weird, I thought that this issue is fixed. At least the author is confirmed that’s fixed.
I reported this to the team.
As turned out, there is still an issue and here is the change: https://review.dev.storj.io/c/storj/gateway-mt/+/11580
So, I hope it will be fixed and released soon.