[IDM] File Permission Issue with ocis-user

Hi everyone,

I got my oCIS setup running to a point where, for data safety, I wanted to use a SMB share mounted on the docker host machine and passed via bind mount to the oCIS container.

The setup

This is how I set it up:

VL : Virtualization Layer

VL 0: Bare metal server running PVE

  • This is where I mount a SMB share which I make available to all VMs and LXCs.
  • It is mounted in the directory /mnt/lxc_shares/cloud with an owner group lxc_shares that has RWX permissions.

VL 1: LXC as Docker host machine

  • I pass the directory on to this LXC under the mount point /mnt/cloud
  • The user of this machine that owns the docker process belongs to the same lxc_shares group.

VL 2: oCIS Container

  • I pass the directory on to the oCIS container via a bind mount:
[...]
volumes:
    # Config
    - ./config/ocis/banned-password-list.txt:/etc/ocis/banned-password-list.txt
    - ./config/ocis/csp.yaml:/etc/ocis/csp.yaml
    - ./config/ocis/proxy.yaml:/etc/ocis/proxy.yaml
    - ocis-config:/etc/ocis
    # Data
    - /mnt/cloud:/var/lib/ocis
[...]
  • So far, the ocis-user is not a part of this group yet, so I created a custom docker image to
    • add a group lxc_shares with the exact same GID (=10000) as the docker host group
    • add the ocis-user to this group to inherit the RWX access

The Dockerfile:

# Use the owncloud/server base image
FROM owncloud/ocis

# Switch to root user
USER root
# Create the system group lxc_shares with GID 10000
RUN addgroup -g 10000 lxc_shares

# Add the default user to the lxc_shares group
RUN addgroup ocis-user lxc_shares
# Switch back to default user
USER ocis-user

With this setup, upon first launch, initial files and directories are created just fine.

This is my go-to approach for most of my containers, because with PVE’s CIFS mounts, I cannot change permissions with chmod or chown. That’s why I need to adapt the users inside the containers to match UID or GID of my mounted directories.

The problem

However, upon first login try, through my external IdP, I am greeted with errors in my container log:

2025-07-18T15:10:28Z INF user idp:"none"  opaque_id:"2c3e410d-f5c9-42bb-b7b9-8f90ea59cf27"  type:USER_TYPE_SERVICE authenticated | service=auth-service pkg=rgrpc traceid=4936e02816316910b2557d4f2ad60708 line=github.com/owncloud/reva/v2@v2.0.0-20250618124252-722b346820da/internal/grpc/services/authprovider/authprovider.go:146

2025-07-18T15:10:28Z ERR invalid credentials | service=idm bind_dn=uid=libregraph,ou=sysusers,o=libregraph-idm op=bind remote_addr=127.0.0.1:41586 line=github.com/owncloud/ocis/v2/ocis-pkg/log/logrus_wrapper.go:50

2025-07-18T15:10:28Z ERR Bind failed | service=graph error=LDAP Result Code 49 "Invalid Credentials":  line=github.com/owncloud/ocis/v2/services/graph/pkg/identity/ldap/reconnect.go:254

2025-07-18T15:10:28Z ERR failed to add user | service=graph request-id=bcf5bc9c1218/hKCN9UQcMt-000062 error=LDAP Result Code 49 "Invalid Credentials":  line=github.com/owncloud/ocis/v2/services/graph/pkg/identity/ldap.go:203

2025-07-18T15:10:28Z ERR could not create user: backend error | service=graph request-id=bcf5bc9c1218/hKCN9UQcMt-000062 error=generalException: failed to add user line=github.com/owncloud/ocis/v2/services/graph/pkg/service/v0/users.go:394

2025-07-18T15:10:28Z WRN Error Response | service=proxy OData Error=failed to add user line=github.com/owncloud/ocis/v2/services/proxy/pkg/user/backend/cs3.go:464

2025-07-18T15:10:28Z ERR Error creating user | service=proxy error=500 Internal Server Error line=github.com/owncloud/ocis/v2/services/proxy/pkg/user/backend/cs3.go:214

2025-07-18T15:10:28Z ERR Autoprovisioning user failed | service=proxy error=500 Internal Server Error line=github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/account_resolver.go:130

I run the following configuration for my oCIS:

[...]
environment:
  # External IDP specific configuration
  PROXY_AUTOPROVISION_ACCOUNTS: "true"
  PROXY_ROLE_ASSIGNMENT_DRIVER: "oidc"
  OCIS_OIDC_ISSUER: https://${AUTHENTIK_DOMAIN}/application/o/owncloud-web/
  PROXY_OIDC_REWRITE_WELLKNOWN: "true"
  WEB_OIDC_CLIENT_ID: ${OCIS_OIDC_CLIENT_ID:-web}
  # general config
  OCIS_URL: https://${OCIS_DOMAIN:-ocis.owncloud.test}
  OCIS_LOG_LEVEL: ${OCIS_LOG_LEVEL:-info}
  OCIS_LOG_COLOR: "${OCIS_LOG_COLOR:-false}"
  PROXY_TLS: "false" # do not use SSL between Traefik and oCIS
  PROXY_USER_OIDC_CLAIM: "preferred_username"
  PROXY_USER_CS3_CLAIM: "username"
  PROXY_AUTOPROVISION_CLAIM_GROUPS: "ocis_groups"
  # INSECURE: needed if oCIS / Traefik is using self generated certificates
  OCIS_INSECURE: "${INSECURE:-false}"
  OCIS_ADMIN_USER_ID: ""
  OCIS_EXCLUDE_RUN_SERVICES: "idp"
  GRAPH_ASSIGN_DEFAULT_USER_ROLE: "false"
  GRAPH_USERNAME_MATCH: "none"
  # password policies
  OCIS_PASSWORD_POLICY_BANNED_PASSWORDS_LIST: "banned-password-list.txt"
  PROXY_CSP_CONFIG_FILE_LOCATION: /etc/ocis/csp.yaml
  PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD: none
[...]

Additional info:

  • IdP: Authentik
  • Reverse Proxy: Traefik
  • all launched through docker compose

Any help as to why the IDM service suddenly throws these errors are greatly appreciated, thanks!

Mmh. Quite strange. We didn’t touch idm service for longer so it’s not related to a recent change. What ocis version are you running?
Looking through the code I find invalid credentials log only in case the given password does not match the stored password. Do you have another user that you could try?

1 Like

Your issue is due to invalid LDAP credentials (LDAP Result Code 49). Check:

  1. Bind DN and password — ensure uid=libregraph,... and its password match Authentik.
  2. OCIS_EXCLUDE_RUN_SERVICES=idp — may be breaking internal IDM needs. Try removing it.
  3. Verify your OIDC settings (OCIS_OIDC_ISSUER, client ID, etc.) match what’s set in Authentik.

Fix the bind credentials or disable IDM fully if using external Authentik.

1 Like

Sorry for the radio silence the past days. The version in use is 7.2.0. Another user of which service?

1 Like

To 1:
I don’t quite get what needs to be matching between Authentik and oCIS.
I still use the internal idm, so DN and password is untouched AFAIK. Authentik is only used for user authentication through external IdP. Am I missing something here?

To 2.:
Will check now.

To 3.:
The weird thing about this is that right before I (config-wise) moved my data directory into the SMB share, I was able to log in just fine with the same OIDC config and user. I didn’t change anything about the config except for the docker bind mount of - /mnt/cloud:/var/lib/ocis.

1 Like

Okay, so I was able to resolve it for me with a workaround:

It looks like, although the ocis_user was able to read and write to the SMB share, some permissions issue (which I wasn’t able to troubleshoot any further) prevented it from symlinking the setting from the metadata service.

I now exchanged my SMB share with an NFS share and gave it the same group owner as the ocis_user (lxc_shares) and that resolved the permission issues. Without any other config changes it just started working again!

Thank you all for your suggestions!

2 Likes