OIDC with Entra ID - WebDAV endpoints return 403 without errors

[lholota]

Hi all,

I have managed to configure OIDC sign in with Entra ID and when it starts fully working I am happy to contribute with a guide towards the OpenCloud docs. The sign in including role assignment works correctly, there are no errors in the container log.

The problem is that authorization seems not to be working correctly on WebDAV endpoints.

The replication case is:

• I sign in using OIDC
• I verify in the administration I have an admin role assigned
• I land in the root page of my files
• I try to upload and end up with a 403 status code (i.e. uploading to user space, not a shared space)

The request which is returning this status code is always a WebDAV request (doesn't matter if it's upload or trying to display contents of a file), URL of the endpoint is https://opencloud.<redacted>/dav/spaces/23868666-7f89-4550-bf06-80e82b21dc56$341a17c4-d359-4e25-9baa-0d35610b2fff

I have tried turning on trace level logs but there was no hint, no errors, no failures.

{"level":"info","service":"auth-machine","host.name":"opencloud-opencloud-9895785f6-dzr87","pkg":"rgrpc","traceid":"8fe3aea81d8a623778c44253a2a5c5a9","time":"2026-08-14T19:00:32Z","line":"github.com/opencloud-eu/reva/v2@v2.48.0/internal/grpc/services/authprovider/authprovider.go:146","message":"user idp:\"https://login.microsoftonline.com/<redacted>/v2.0\"  opaque_id:\"341a17c4-d359-4e25-9baa-0d35610b2fff\"  type:USER_TYPE_PRIMARY authenticated"}
{"level":"info","service":"storage-users","host.name":"opencloud-opencloud-9895785f6-dzr87","pkg":"rgrpc","traceid":"8fe3aea81d8a623778c44253a2a5c5a9","data-server":"http://localhost:9158/data/simple/68fa5edd-175d-4879-9fe8-2283939e0668","fn":"./Immich Icon.png","xs":"map[md5:100 unset:1000]","time":"2026-08-14T19:00:32Z","line":"github.com/opencloud-eu/reva/v2@v2.48.0/internal/grpc/services/storageprovider/storageprovider.go:470","message":"file upload"}
{"level":"info","service":"storage-users","host.name":"opencloud-opencloud-9895785f6-dzr87","pkg":"rgrpc","traceid":"8fe3aea81d8a623778c44253a2a5c5a9","data-server":"http://localhost:9158/data/tus/68fa5edd-175d-4879-9fe8-2283939e0668","fn":"./Immich Icon.png","xs":"map[md5:100 unset:1000]","time":"2026-08-14T19:00:32Z","line":"github.com/opencloud-eu/reva/v2@v2.48.0/internal/grpc/services/storageprovider/storageprovider.go:470","message":"file upload"}
{"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"21938c50-5a28-43da-acf7-80af877885d4","traceid":"8fe3aea81d8a623778c44253a2a5c5a9","remote-addr":"93.99.216.106","method":"POST","status":403,"path":"/dav/spaces/23868666-7f89-4550-bf06-80e82b21dc56$341a17c4-d359-4e25-9baa-0d35610b2fff","duration":80.863323,"bytes":0,"time":"2026-08-14T19:00:32Z","line":"github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}

The container configuration is

env:
    - name: OC_URL
      value: https://opencloud.<redacted>
    - name: GRAPH_AVAILABLE_ROLES
      value: >-
        b1e2218d-eef8-4d4c-b82d-0f1a1b48f3b5,a8d5fe5e-96e3-418d-825b-534dbdf22b99,fb6c3e19-e378-47e5-b277-9732f9de6e21,58c63c02-1d89-4572-916a-870abc5a1b7d,2d00ce52-1fc2-4dbc-8b95-a73b73395f5a,1c996275-f1c9-4e71-abdf-a42f6495e960,312c0871-5ef7-4b3a-85b6-0e4074c64049,aa97fe03-7980-45ac-9e50-b325749fd7e6
    - name: OC_LOG_LEVEL
      value: info
    - name: OC_LOG_COLOR
      value: "false"
    - name: OC_LOG_PRETTY
      value: "false"
    - name: PROXY_TLS
      value: "false"
    - name: GATEWAY_GRPC_ADDR
      value: 0.0.0.0:9142
    - name: OC_INSECURE
      value: "true"
    - name: PROXY_ENABLE_BASIC_AUTH
      value: "false"
    - name: COMPANION_DOMAIN
      value: companion.<redacted>
    - name: OC_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD
      value: "false"
    - name: OC_PASSWORD_POLICY_BANNED_PASSWORDS_LIST
      value: banned-password-list.txt
    - name: GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN
      value: "true"
    - name: SEARCH_EXTRACTOR_TYPE
      value: tika
    - name: SEARCH_EXTRACTOR_TIKA_TIKA_URL
      value: http://opencloud-tika:9998
    - name: OC_ASYNC_UPLOADS
      value: "false"
    - name: OC_GRPC_MAX_RECEIVED_MESSAGE_SIZE
      value: "102400000"
    - name: OC_JWT_SECRET
       value: VJnaJfETLEBBdR8hQIVaGtS51smX2WE8
    - name: OC_MACHINE_AUTH_API_KEY
      value: kJ42BPz9LBw3Rt6BASlNFIryMXUbPuNp
    - name: OC_TRANSFER_SECRET
      value: Zj6cM0iNPS6v3dAyNCjQtu6fJmmjMIrh
    - name: OC_SERVICE_ACCOUNT_SECRET
      value: nJcu8W4mqNef4BwsEfdUAjVPZI1fm1Eb
    - name: OC_SERVICE_ACCOUNT_ID
      value: 95fb9817-d9a5-493a-a87b-87bc31602861
    - name: IDM_SVC_PASSWORD
      value: 8hZugx3LHamUMmQIGvBYL2kBgQBb1ni1
   - name: IDM_REVASVC_PASSWORD
      value: saUL4VAwYLWYbEI65Qzg5IFtSmriDlL5
    - name: IDM_IDPSVC_PASSWORD
      value: Vx2o4YMdQQ1CEX3XSmu0JnPCJaEltPNc
    - name: OC_ADMIN_USER_ID
      value: fc4d0b80-cb2f-4ad2-8d1b-7d81d3262ae7
    - name: COLLABORATION_WOPI_SECRET
      value: hEptqDaNFkUwN0kXkJI3U2Z4V7BUnldv
    - name: OC_SYSTEM_USER_API_KEY
      value: BSf8KHnpOgM8bnJ3DlBZ6Ke3OjBUAbaE
    - name: OC_URL_SIGNING_SECRET
      value: RPZJi31TS5FBJoLEQZP7PsLXJiS4UoXH
    - name: THUMBNAILS_TRANSFER_TOKEN
      value: x1MXW57Hb7WdTTbLIcpFL2NOxlrSRQdA
    - name: OC_SYSTEM_USER_ID
      value: e4e1de10-34ca-48ab-be4b-8d46dfcbd2a8
    - name: GRAPH_APPLICATION_ID
      value: 549ee36a-3c0f-4153-8753-480fc5364555
    - name: STORAGE_USERS_MOUNT_ID
      value: 23868666-7f89-4550-bf06-80e82b21dc56
    - name: GATEWAY_STORAGE_USERS_MOUNT_ID
      value: 23868666-7f89-4550-bf06-80e82b21dc56
    - name: SETTINGS_SERVICE_ACCOUNT_IDS
      value: 95fb9817-d9a5-493a-a87b-87bc31602861
    - name: USERS_LDAP_BIND_PASSWORD
      value: saUL4VAwYLWYbEI65Qzg5IFtSmriDlL5
    - name: GROUPS_LDAP_BIND_PASSWORD
      value: saUL4VAwYLWYbEI65Qzg5IFtSmriDlL5
    - name: AUTH_BASIC_LDAP_BIND_PASSWORD
      value: saUL4VAwYLWYbEI65Qzg5IFtSmriDlL5
    - name: IDP_LDAP_BIND_PASSWORD
      value: Vx2o4YMdQQ1CEX3XSmu0JnPCJaEltPNc
    - name: GRAPH_LDAP_BIND_PASSWORD
      value: 8hZugx3LHamUMmQIGvBYL2kBgQBb1ni1
    - name: IDM_ADMIN_PASSWORD
      value: r0gdEwV-soZz-PJM4Mo__u1HruTug9lfhnN_1YDTiv
    - name: IDM_CREATE_DEMO_USERS
      value: "true"
    - name: MICRO_REGISTRY_ADDRESS
      value: 127.0.0.1:9233
    - name: NATS_NATS_HOST
      value: 0.0.0.0
    - name: NATS_NATS_PORT
      value: "9233"
    - name: OC_EVENTS_ENDPOINT
      value: 127.0.0.1:9233
    - name: OC_CACHE_STORE_NODES
      value: 127.0.0.1:9233
    - name: OC_PERSISTENT_STORE_NODES
      value: 127.0.0.1:9233
    - name: PROXY_CSP_CONFIG_FILE_LOCATION
      value: /etc/opencloud/csp.yaml
    - name: STORAGE_USERS_DRIVER
      value: decomposed
    - name: STORAGE_SYSTEM_DRIVER
      value: decomposed
    - name: STORAGE_USERS_OC_MAX_CONCURRENCY
      value: "100"
    - name: PROXY_AUTOPROVISION_ACCOUNTS
      value: "true"
    - name: FRONTEND_CHECK_FOR_UPDATES
      value: "false"
    - name: FRONTEND_READONLY_USER_ATTRIBUTES
      value: "true"
    - name: PROXY_ROLE_ASSIGNMENT_DRIVER
      value: oidc
    - name: OC_OIDC_ISSUER
      value: https://login.microsoftonline.com/<redacted>/v2.0
    - name: WEB_OPTION_ACCOUNT_EDIT_LINK_HREF
    - name: PROXY_OIDC_REWRITE_WELLKNOWN
      value: "true"
    - name: WEB_OIDC_CLIENT_ID
      value: <redacred>
    - name: PROXY_OIDC_SKIP_USER_INFO
      value: "true"
    - name: PROXY_USER_OIDC_CLAIM
      value: preferred_username
    - name: PROXY_USER_CS3_CLAIM
      value: username
    - name: PROXY_AUTOPROVISION_CLAIM_USERNAME
      value: preferred_username
    - name: PROXY_AUTOPROVISION_CLAIM_EMAIL
      value: email
    - name: PROXY_AUTOPROVISION_CLAIM_DISPLAYNAME
      value: name
    - name: GRAPH_ASSIGN_DEFAULT_USER_ROLE
      value: "false"
    - name: GRAPH_USERNAME_MATCH
      value: none
    - name: PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM
      value: roles
    - name: PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD
      value: jwt
    - name: WEB_OIDC_SCOPE
      value: openid profile email 689cb293-306c-47fc-8ad0-60c6124ae358/.default

[yudin-s]

First, rotate the secrets/passwords from the compose/env snippet. There are several real-looking shared secrets in the post, and GitHub discussions are public.

For the 403 itself, I would separate "OIDC login/role mapping works" from "the personal home space exists". The admin role mapping can be correct while WebDAV for the user's personal space still fails.

The suspicious setting is:

GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN=true

In OpenCloud that flag is passed to the Reva gateway as disable_home_creation_on_login. When it is enabled, login does not create the user's home space. Your failing URL is a personal-space WebDAV URL:

/dav/spaces/{STORAGE_USERS_MOUNT_ID}${opaque_id}

So the symptom fits a user that authenticated successfully, received roles, but has no personal space/home yet.

I would test this first:

1. Set GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN=false or remove that override.
2. Restart OpenCloud/gateway/proxy.
3. Sign in with a fresh OIDC user and retry the WebDAV request.
4. Compare with an existing built-in/demo user, if you have one.

If that fixes it, the OIDC mapping was not the primary problem; you either need login-time home creation enabled or a separate provisioning step that creates personal spaces before those users access WebDAV.

If this solves it, please mark the answer so the next person with a 403 on /dav/spaces/... can find the home-space cause quickly.

[lholota]

Hi @yudin-s, thanks a lot for the suggestion! The secrets are temporary, so you don't need to worry about those.

I have tried setting GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN=false this unfortunately just ended with errors below. I have rerun the container with GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN=true again and I can see directories created under /var/lib/openloud/storage/users/spaces/... with the user id which was assigned to my user account. So it looks like the home is getting created. Is there something else expected to be created during the autoprovisioning?

{"level":"error","service":"proxy","error":"could not get user by claim username with value <redacted> : error creating user home ","time":"2026-08-16T12:00:48Z","line":"github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/account_resolver.go:183","message":"Could not get user by claim"}
{"level":"error","service":"gateway","host.name":"opencloud-opencloud-546ffb4b79-snh8m","pkg":"rgrpc","traceid":"8acf10efc5e053f01a2a2f6669daa363","error":"gateway: grpc failed with code CODE_PERMISSION_DENIED","time":"2026-08-16T12:00:48Z","line":"github.com/opencloud-eu/reva/v2@v2.48.0/internal/grpc/services/gateway/authprovider.go:139","message":"error calling Createhome"}

[yudin-s]

Thanks, that log changes the likely failure point.

With GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN=false, OpenCloud does not just look for an existing directory. In the gateway auth path it authenticates the user, mints a token, puts that token/user into the outgoing context, then calls CreateHome. Your log is from that call returning CODE_PERMISSION_DENIED, so I would treat this as "home creation was attempted but the storage provider rejected it", not as "the directory already exists and WebDAV should work".

The directories under /var/lib/opencloud/storage/users/spaces/... are a useful clue, but I would not use them as the only success criterion. The user also needs a valid personal-space resource/metadata entry that the gateway can resolve for /dav/spaces/{STORAGE_USERS_MOUNT_ID}$opaque_id.

I would check three things next:

1. Keep GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN=false for the test and capture the storage-users/decomposedfs log lines at the same timestamp as Createhome. The proxy/gateway line only shows the wrapped permission error; the storage service should say what permission/input it rejected.
2. Verify that your OIDC claim mapping is stable and matches the user that was provisioned: PROXY_USER_OIDC_CLAIM defaults to preferred_username, and PROXY_USER_CS3_CLAIM defaults to username. If Entra changes that value or it differs from the already-created account, you can end up resolving/provisioning a user differently than expected.
3. Check whether this user was originally created while home creation was disabled. If so, test with a completely fresh OIDC user after enabling home creation, or remove the half-created test user through the supported admin path before retrying. A filesystem directory left behind is not necessarily the same as a complete personal space.

So the answer to "is something else expected" is probably yes: not just directories on disk, but successful CreateHome registration/metadata for the user's personal space. The next useful evidence is the storage-users log around the CODE_PERMISSION_DENIED; that should separate claim/user mismatch from storage permission/metadata creation failure.

[lholota]

Hi @yudin-s ,

I've tried rerunning the server with GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN=false. For every test run I start with completely empty storage and restarted container so the state should be completely clear.

I actually had the same thought during the previous test run a couple days ago but I couldn't find any storage related error. One thing I don't know is what's the order of operations - is the home dir created first and user record after or the user record first and the directory after? I am trying to understand if the user can't be found because creating home has failed or the other way around.

Regards point 2, I have investigated the tokens (both access and id tokens), the preferred_username claim is present and is equal to email. I have also tried rerunning the deployment with PROXY_USER_CS3_CLAIM=mail and PROXY_USER_OIDC_CLAIM=email (email claim is also present in both tokens and has the same value) but the error is still the same.

What I still can't understand is that the main error is that it can't find the user but which suggest the problem could be the user not being properly created in idm but when I disable creating home, the user gets apparently created because I can see the account in the admin/users screen.

Attaching full logs for completness app-opencloud-opencloud-opencloud-547bd6bc4b-r5rzx-opencloud.log

Logs are redacted:

• Real e-mail address replaced with mail@example.com
• Real url replaced with opencloud.<redacted>
  Otherwise the log is in original shape. It's from the start of the container (again, completely fresh, nothing in the storage), signing in with OIDC ending with error.