Hi there,

Same issue. Got the error 'cannot read config at \"/home/opuser/.op/config\": Can't continue. We can't safely access \"/home/opuser/.op/config\" because its permissions are too broad. Change its permissions to 600 and try again.'

I was able to resolve the issue by issuing 'chmod 600 /home/opuser/.op/config' inside the container, however, the change is not persistent.

timchambers I'm very sorry to hear about the continual problems we're having. There's a clear issue with our current deployment and we are working to get a permanent fix release ASAP. There is something that we suspect is causing this issue related to filesystem permissions. Since I can't see your logs, its impossible for me to be 100% certain that this is the same problem. Regardless, you can try this fix below:

```

Upgrade to 2.6.2 (if you need to)

kubectl set image deploy/op-scim-bridge-1 op-scim-bridge-1=1password/scim:v2.6.2

Patch initContainer command args

kubectl patch deploy/op-scim-bridge-1 -p='{"spec":{"template":{"spec":{"initContainers":[{"name":"opuser-home-permissions","args":["mkdir -p /home/opuser/.op && chown -R 999 /home/opuser && chmod 700 /home/opuser && chmod 700 /home/opuser/.op && umask 177 /home/opuser/.op"]}]}}}}'

Change existing config file permissions

kubectl exec -it deploy/op-scim-bridge-1 -c op-scim-bridge-1 -- chmod 600 /home/opuser/.op/config
```

If after running the commands, you're still having trouble with the SCIM bridge, download your SCIM bridge logs following the instructions here (doesn't require your bearer token): https://support.1password.com/cs/scim-logs/

Attach them in a message to mailto:businesssupport@1password.com, and my colleagues will be able to take a closer look. We're currently tracking this problem for other customers and would love to give direct help as it will also help us permanently resolve the issue faster.

Thanks a ton for your patience, and our apologies again for the broken version.

@"laz.h_1P" For what it's worth, when in this state, it's not possible to sign into the SCIM bridge at all. I ended up removing and recreating the cluster and redeploying the SCIM bridge to get things working again—I'm getting pretty good at it due to this issue. Do you anticipate a fix to this issue so that we can reliably use the SCIM bridge going forward? It's hard to justify paying the ongoing expense of a cluster that sits unused an not syncing our users and groups after some unpredictable period of time.

After some more digging into this and speaking to colleagues there may be an alternative, simpler workaround (until we get in a permanent fix for this, of course). If you are able go into the bridge UI and disable Workspace (this can be done by removing your credentials file or configuration), then re-enable it by replacing the same data it will cause the Workspace server to restart and likely fix the issue.

If this doesn't work, the specific documentation can be found in the https://support.1password.com/scim-troubleshooting/ guide. Hope this helps!

We've also encountered this a couple times now, running 2.6.2. The first time this happened, I ended up performing a complete redeploy on GCP to get this working again with Google Workspace. This has now happened again. This usually manifests first when I noticed that group changes haven't synced correctly to 1Password, then I attempt to sign into the SCIM bridge to manually sync things, except that I cannot because of this "failed to create session" error.

I'm now attempting to regenerate credentials. Could you provide documentation on the specific steps you mentioned: "and then configure it on your IdP and then swap out the token on the bridge"?

Hi huyngo, my apologies for the late response. I'm Laz, a developer on the SCIM bridge. Its very unusual for the bearer token to suddenly stop working. Are you the only administrator of the account? If not, its possible that someone else went onto the account and accidentally invalidated / regenerated the bearer token. Regardless, if you go into the integration page you are able to regenerate a new bearer token and then configure it on your IdP and then swap out the token on the bridge. Sorry to hear that this has happened to you! I wish I could offer more direct advise, but as you said its hard to determine anything 100% without seeing the logs