Hopefully posting to the right area… (apologies if not).
The most recent version of the IOS app (2.5.1) on IOS 26.2 has an issue. It took a good bit of testing to try to figure out -what- the actual error meant and/or what it pertained to. Eventually realizing that it only occurs on folders that are “shared”. The server is CE 5.8.0 - ensured that everything was up to date this evening as part of trying to determine the issue. Runs on a Debian bookworm instance with php8.2 - healthcheck passes, states passbolt ce is on latest.
Issue description:
Very small (self hosted) instance with <10 users. Each user shares a couple password folders with 1+ other users or to a “group”. In testing, all of the following fail with the same error (shown below):
Folder shared by owner to a single user, read only
Folder shared by owner to a single user, can update
Folder shared by owner to a group, read only
Folder shared by owner to a group, can update
(did not test other possible combinations, as they aren’t used in this scenario)
For all folders being “shared”, the user (owner) is unable to edit any of their own entries in the Folder (via the IOS app, but works just fine via web browser). When they tap the three circles and then select “Edit” at the bottom, they receive the message: “You cannot perform this action because you lack access to the shared metadata key.” The error flashes briefly at the bottom of the screen, with a red background and then disappears. The moment the Folder is not “shared” - the user is able to edit any of their records (that they originally created) within the Folder, via the IOS passbolt app. For clarity, ALL of the records in the Folder were created by the -same- user, that is now prohibited from modifying their records if the Folder is “shared”. This does not happen when working with a web browser (Librewolf, as example) - the user is able to modify their records. As this configuration (shared folders) has been utilized for quite a while (well prior to 5.x) - don’t recall this issue being present previously with the IOS app. (Admittedly, most changes are via browser with changes via the IOS app being infrequent. IOS app is mostly used to ‘copy’ a password for use and not ‘update’ records).
Unable to express -when- this error started happening, as a recent attempt to change a record brought this issue to awareness.
Hopefully someone here may have already encountered this error and knows how to correct it.
I am having exactly the same error here since version 5.6, I have updated passbolt to 5.8 and 5.9.0 CE now and the same issue still happens. Other than the steps you have mentioned, I have also removed the app from my phone and reinstalled, tried to remove the account from the phone and added again.
As you said, I can normally edit everything from the web interface but NOT from the ios app.
The only difference compared to your scenario is that I am running Passbolt as a docker container.
In my case, if the “folders” can’t be shared - the amount of effort by a given user (not to mention the “forgot to share” factor) would be highly problematic. Will need some time to get things changed to test the scenario, for which you asked.
Not seeing any settings tabs for the items to which you are referring.
Looks like the encrypted metadata isn’t present, but the iOS app is still trying to access it - this appears to be an iOS app issue.
I’ll investigate further and keep you posted once I have an ETA for the fix.
Turning it on should resolve the issue. We found that some configuration required by iOS isn’t sent from server when there’s no Metadata Key present (even if it’s not being used).
If you’d rather not enable Encrypted Metadata, you can also wait for the next iOS app release - we’ve already prepared it with a fix and it should be out in the next couple of days (I count for Tuesday ).
It might help you @eduoliveira13 as well, although I can’t prove it without a screenshot.
Great to know. I will wait for the next ios update since this is not critical at the moment for us. Anyway, as soon as the update is available I will install and come back here to share my findings. Including testing the option you provided and print screens.
Interesting. When I went to the Getting Started panel, the radio button already shows that encrypted metadata is selected (not legacy/cleartext). Also - good to know where that setting is. So unless it’s showing encrypted metadata as a “you should select this” - it’s already selected.
If it’s the later and meaning “you should select this” - I can snapshot the VM, enable and test. Only concern would be if it creates a problem on the passbolt clients if they see it “enabled” and then it gets rolled back to disabled.
@doubts we are encouraging users to adopt this capability because it provides stronger security, and that’s not something we can compromise on. Currently, only new instances lack an easy way to revert to legacy resources, but eventually legacy will be disabled for everyone when creating new resources.
In the meantime, all clients should continue working with legacy-back resource types. I’ve tested this on one of my cloud test instances, and the type of issue you’re describing does not occur there. The defect we identified was that the iOS app expects specific metadata endpoints. If the feature is enabled on the API and later disabled, the API still returns the required responses for iOS, so I assume your scenario should be fixed like my cloud one.
@eduoliveira13 It seems there may be more going on here than we expected. Let’s wait for the 2.6.1 app release, as that update may resolve this issue as well.
Understood. In the meantime, did update the passbolt instance to 5.9.0-1 (as shown by dpkg on Debian). Happy to wait for the next IOS release and test then as well.
).