OpenCloud: OCM Share Receiving Problems

by ADMIN 40 views

Hey guys, this article dives into a problem we're seeing with OpenCloud and how it handles OCM (Open Cloud Mesh) shares from other EFSS (Enterprise File Sync and Share) systems. We're looking at why OpenCloud is having trouble receiving these shares, especially when they come from different platforms like CERNBox. Let's break down the issue, look at the technical details, and figure out what's going on.

OpenCloud to OpenCloud: The Basics

Let's assume everything's set up and we've already done the whole invitation thing. Now, we're sharing files between two OpenCloud instances. Let's look at the flow:

Share Sender (OpenCloud 1)

Let's say our user is alan. He's trying to share a file called opencloud-to-opencloud.md and this is how the share payload looks:

{
  "shareWith": "cd88bf9a-dd7f-11ef-a609-7f78deb2345f@https://2.opencloud.cloud.test.azadehafzar.io",
  "name": "opencloud-to-opencloud.md",
  "description": "",
  "providerId": "RED-ACTED",
  "owner": "YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw==@1.opencloud.cloud.test.azadehafzar.io",
  "sender": "YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw==@1.opencloud.cloud.test.azadehafzar.io",
  "ownerDisplayName": "",
  "senderDisplayName": "Alan Turing",
  "shareType": "user",
  "expiration": 0,
  "resourceType": "file",
  "protocol": {
    "name": "multi",
    "options": {},
    "webdav": {
      "sharedSecret": "RED-ACTED",
      "permissions": [
        "read"
      ],
      "url": "https://1.opencloud.cloud.test.azadehafzar.io/dav/ocm/RED-ACTED"
    }
  }
}

The Problem with shareWith

One thing to note here: the "shareWith" field is where we specify who we're sharing with. According to the OCM specification, this field should use an OCM Address format. However, the https:// part shouldn't actually be there, according to the official guidelines. Think of it like this: the protocol is already implied, and we just need the address.

Share Receiver (OpenCloud 2)

Our user here is dennis. Let's see what happens on his end, checking the logs:

  1. Finding the Provider: OpenCloud 2 figures out which provider the share is coming from using the "sender" field.

    2025-10-15T20:44:50Z DBG Determined Mesh Provider '1.opencloud.cloud.test.azadehafzar.io' from req.Sender 'YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw==@1.opencloud.cloud.test.azadehafzar.io' line=github.com/opencloud-eu/reva/v2@v2.37.0/internal/http/services/ocmd/shares.go:93 pkg=rhttp request-id=7b7530defb22/Wmn8DhtC62-001041 service=ocm traceid=cf02ebd3642724dc5407e527f9b46f47

  2. Getting the User: It extracts the user from the "shareWith" field. It only grabs the opaque_id part of the OCM Address, which is the unique identifier.

    2025-10-15T20:44:50Z DBG GetUser id={"opaque_id":"cd88bf9a-dd7f-11ef-a609-7f78deb2345f"} line=github.com/opencloud-eu/reva/v2@v2.37.0/pkg/user/manager/ldap/ldap.go:101 pkg=rgrpc service=users traceid=c918599df4448656e464e1996012810e

  3. LDAP Searches: OpenCloud then performs several LDAP (Lightweight Directory Access Protocol) searches to find the user. It uses the opaque_id directly in the search without changing it. It is using cd88bf9a-dd7f-11ef-a609-7f78deb2345f in the search query.

    2025-10-15T20:44:50Z DBG LDAP Search backend=ldap basedn=ou=users,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(openclouduuid=cd88bf9a-dd7f-11ef-a609-7f78deb2345f)) line=github.com/opencloud-eu/reva/v2@v2.37.0/pkg/utils/ldap/identity.go:220 pkg=rgrpc scope=2 service=users traceid=c918599df4448656e464e1996012810e

2025-10-15T20:44:50Z DBG Calling boltdb search attrs=["displayname","openclouduuid","","mail","uid","uidNumber","gidNumber","openclouduserenabled","openCloudUserType"] basedn=ou=users,o=libregraph-idm binddn=uid=reva,ou=sysusers,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(openclouduuid=cd88bf9a-dd7f-11ef-a609-7f78deb2345f)) line=github.com/opencloud-eu/opencloud/pkg/log/logrus_wrapper.go:50 op=search service=idm

2025-10-15T20:44:50Z DBG boltdb search returned 3 entries attrs=["displayname","openclouduuid","","mail","uid","uidNumber","gidNumber","openclouduserenabled","openCloudUserType"] basedn=ou=users,o=libregraph-idm binddn=uid=reva,ou=sysusers,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(openclouduuid=cd88bf9a-dd7f-11ef-a609-7f78deb2345f)) line=github.com/opencloud-eu/opencloud/pkg/log/logrus_wrapper.go:50 op=search service=idm

    Important Point: OpenCloud uses the opaque_id directly in the LDAP search. It doesn't modify it or decode anything, which can cause issues.

  4. User Found: Finally, the system finds the user's information.

    2025-10-15T20:44:50Z DBG entries entry={"Attributes":[{"ByteValues":["RGVubmlzIFJpdGNoaWU="],"Name":"displayName","Values":["Dennis Ritchie"]},{"ByteValues":["ZGVubmlzQGV4YW1wbGUub3Jn"],"Name":"mail","Values":["dennis@example.org"]},{"ByteValues":["Y2Q4OGJmOWEtZGQ3Zi0xMWVmLWE2MDktN2Y3OGRlYjIzNDVm"],"Name":"openCloudUUID","Values":["cd88bf9a-dd7f-11ef-a609-7f78deb2345f"]},{"ByteValues":["VFJVRQ=="],"Name":"openCloudUserEnabled","Values":["TRUE"]},{"ByteValues":["ZGVubmlz"],"Name":"uid","Values":["dennis"]}],"DN":"uid=dennis,ou=users,o=libregraph-idm"} line=github.com/opencloud-eu/reva/v2@v2.37.0/pkg/user/manager/ldap/ldap.go:112 pkg=rgrpc service=users traceid=c918599df4448656e464e1996012810e

Others (CERNBox) to OpenCloud: Another Scenario

Let's switch gears and see what happens when CERNBox, another EFSS, shares with OpenCloud. This is a bit different because of the invitation process.

Invitation Flow

CERNBox shares a token with OpenCloud, and OpenCloud then sends this payload to accept the share:

{
  "email": "alan@example.org",
  "name": "Alan Turing",
  "recipientProvider": "1.opencloud.cloud.test.azadehafzar.io",
  "token": "ed305914-b7ea-4b4e-a889-41a7217053c7",
  "userID": "YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw=="
}

So, CERNBox stores the YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw==@1.opencloud.cloud.test.azadehafzar.io as an OCM Address.

Also, according to the OCM specification, the "userID" shouldn't be touched by the receiver (OpenCloud). It should be exactly as the sender knows it.

If you decode the base64-encoded "userID", you get: b1f74ec4-dd7e-11ef-a543-03775734d0f7@https://1.opencloud.cloud.test.azadehafzar.io

Share Sender (CERNBox)

Our user is lopresti. CERNBox uses the OCM Address obtained during the invite process.

Here's the share payload:

{
  "shareWith": "YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw==@1.opencloud.cloud.test.azadehafzar.io",
  "name": "shared_via_ocm.txt",
  "description": "",
  "providerId": "RED-ACTED",
  "owner": "lopresti@qa.cernbox.cern.ch",
  "sender": "lopresti@qa.cernbox.cern.ch",
  "ownerDisplayName": "",
  "senderDisplayName": "Giuseppe Lo Presti",
  "code": "",
  "shareType": "user",
  "resourceType": "file",
  "expiration": 0,
  "protocol": {
    "name": "multi",
    "options": {},
    "webapp": {
      "uri": "https://qa.cernbox.cern.ch/external/sciencemesh/RED-ACTED/{relative-path-to-shared-resource}",
      "viewMode": "",
      "sharedSecret": ""
    },
    "webdav": {
      "sharedSecret": "RED-ACTED",
      "permissions": [
        "read"
      ],
      "uri": "https://qa.cernbox.cern.ch/remote.php/dav/ocm/RED-ACTED"
    }
  }
}

Share Receiver (OpenCloud 1)

Our user is alan again. Let's see what happens on the receiving end. The logs tell the story:

  1. Finding the Provider: OpenCloud determines the provider from the "sender" field.

    2025-10-15T10:00:55Z DBG Determined Mesh Provider 'qa.cernbox.cern.ch' from req.Sender 'lopresti@qa.cernbox.cern.ch' line=github.com/cs3org/reva/v2@v2.27.7/internal/http/services/ocmd/shares.go:91 pkg=rhttp request-id=46075842a68b/58Z5gnwZ0Q-000100 service=ocm traceid=4df953e7eaba2e5ecb0bac5f8b724800

  2. Getting the User: OpenCloud extracts the user from the "shareWith" field, grabbing only the opaque_id.

    2025-10-15T10:00:55Z DBG GetUser id={"opaque_id":"YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw=="} line=github.com/cs3org/reva/v2@v2.27.7/pkg/user/manager/ldap/ldap.go:101 pkg=rgrpc service=users traceid=34778013c46575d69193c8c7f8497cca

  3. LDAP Searches: OpenCloud tries to find the user using the extracted opaque_id in the LDAP search, just like before.

    2025-10-15T20:44:50Z DBG LDAP Search backend=ldap basedn=ou=users,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(openclouduuid=YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw==)) line=github.com/opencloud-eu/reva/v2@v2.37.0/pkg/utils/ldap/identity.go:220 pkg=rgrpc scope=2 service=users traceid=c918599df4448656e464e1996012810e

2025-10-15T20:44:50Z DBG Calling boltdb search attrs=["displayname","openclouduuid","","mail","uid","uidNumber","gidNumber","openclouduserenabled","openCloudUserType"] basedn=ou=users,o=libregraph-idm binddn=uid=reva,ou=sysusers,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(openclouduuid=YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw==)) line=github.com/opencloud-eu/opencloud/pkg/log/logrus_wrapper.go:50 op=search service=idm

2025-10-15T20:44:50Z DBG boltdb search returned 3 entries attrs=["displayname","openclouduuid","","mail","uid","uidNumber","gidNumber","openclouduserenabled","openCloudUserType"] basedn=ou=users,o=libregraph-idm binddn=uid=reva,ou=sysusers,o=libregraph-idm filter=(&(objectclass=inetOrgPerson)(openclouduuid=YjFmNzRlYzQtZGQ3ZS0xMWVmLWE1NDMtMDM3NzU3MzRkMGY3QGh0dHBzOi8vMS5vcGVuY2xvdWQuY2xvdWQudGVzdC5hemFkZWhhZnphci5pbw==)) line=github.com/opencloud-eu/opencloud/pkg/log/logrus_wrapper.go:50 op=search service=idm

  4. User NOT Found! Here's the kicker: The system fails to find the user.

    2025-10-15T10:00:55Z ERR user not found error="user not found" line=github.com/cs3org/reva/v2@v2.27.7/internal/http/services/reqres/reqres.go:64 pkg=rhttp request-id=46075842a68b/58Z5gnwZ0Q-000100 service=ocm traceid=4df953e7eaba2e5ecb0bac5f8b724800

    This means OpenCloud can't find a user matching that opaque_id, and the share fails.

Conclusion: The Core Issue

So, what's going on? It looks like OpenCloud is treating the OCM Address in a way that causes problems, especially when sharing with other systems like CERNBox. If OpenCloud sends a base64-encoded identifier to other systems, it should handle the decoding on its end. If it relies on the remote system to do the decoding, that's outside of the OCM specification. In a nutshell, OpenCloud needs to be smarter about how it handles these identifiers to make sure sharing works correctly with everyone.