Permssion issues

[evoandroidevo]

I have been trying to implement this as i really like the idea but when I try to run this as any user other than default i get an error about the permissions on /config but get permission issues with the app im trying to give secrets to if i run it as 65532

locket-auth  | 2026-06-23T08:21:24.671597Z  INFO Starting locket v0.17.3 `run` service 
locket-auth  | 2026-06-23T08:21:24.683462Z ERROR access denied: op login failed: couldn't start daemon: Can't continue. We can't safely access "/tmp/com.agilebits.op.SingleUserEnvironment" because it's not owned by the current user. Change the owner or logged in user and try again.
locket-auth  | [ERROR] 2026/06/23 08:21:24 cannot create directory "/config/op" and the parent directories: mkdir /config/op: permission denied exit_code=77
locket-auth exited with code 77

im not sure if im reading something wrong or have something miss configured

Appreciate the help

  locket:
    image: ghcr.io/bpbradley/locket:op
    user: '1000:1000'
    container_name: locket-auth
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    command:
      - '--provider=op'
      - '--mode=one-shot'
      - '--inject-failure-policy=error'
      - '--log-level=info'
      - '--user=1000:1000'
      - '--file-mode=0600'
      - '--dir-mode=0700'
      - '--op-token=file:/run/secrets/op_token'
      - '--secret=encryption_key={{ op://path/encryption_key }}'
    secrets:
      - op_token
    volumes:
      - secrets-store:/run/secrets/locket

[bpbradley]

Yes I wrestled this quite a bit and generally found a solution that works, but the op cli is -very- finnicky with its security posture. I thought I got this finally fixed but apparently it is still able to cause problems. Basically, the issue is that op cli makes very strict checks on the ownership of the tmp files (even though it really doesn't even need to manage tmp files for this application....) and there are some superficial checks it makes that raise flags. For instance, in this case the issue may be that the uid 1000 does not have a named user in the OS (because I only created "users" for root and the default user).

A future update I intend to try to move to a different solution for service accounts (writing a small golang tool with 1password sdk and using Rust FFI to link it, because for some reason 1password doesn't support a Rust SDK even though 1password is written in Rust...)

Anyway, in the meantime, there are a few alternatives. Go through one by one basically until it works

1. Optional: Move to 1password connect. It is faster, and doesn't have this issue. But I do get the convenience of using a service account token, so the other options are...
2. If the issue is the named user check, which I suspect it is, I have had success mounting in an /etc/passwd file to the contianer which names your user. You can just create one to use for locket, or simpler just mount in your own as read only. I mention it here: https://github.com/bpbradley/locket/blob/main/docs/providers/op.md#workaround-for-arbitrary-non-root-users

Basically, you add this line to your volumes:

 - /etc/passwd:/etc/passwd:ro # Mount /etc/passwd (can be a separate, stripped down version with just one user if desired)

3. You -may- but again I hope generally you dont, but you -may- need to mount in a config directory with the correct permissions. So something like - op-cfg:/config:rw # Mount config directory

with a section like

volumes:
  op-cfg: { driver: local, driver_opts: { type: tmpfs, device: tmpfs, o: "uid=1000,gid=1000,mode=0700" } }

5. Finally, again I think this isn't necessary anymore, but the last think is you may need to mount in a tmp. So in your volumes you would add

- type: tmpfs
              target: /tmp
              tmpfs:
                  mode: 01777

But again I don't think you should need that.

So a full example is:

# Create cfg volume with defined permissions. Can also bind mount one if permissions are correct
volumes:
  op-cfg: { driver: local, driver_opts: { type: tmpfs, device: tmpfs, o: "uid=1000,gid=1000,mode=0700" } } #IF needed
  out-op: { driver: local, driver_opts: { type: tmpfs, device: tmpfs, o: "uid=1000,gid=1000,mode=0700" } }

services:
  locket:
    image: ghcr.io/bpbradley/locket:op
    user: "1000:1000"
    container_name: locket
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    secrets:
      - op_token
    volumes:
      - ./templates:/templates:ro
      - out-op:/run/secrets/locket
      - op-cfg:/config:rw # IF needed: Mount config directory
      - /etc/passwd:/etc/passwd:ro # Probably needed: Mount /etc/passwd (can be a separate, stripped down version with just one user if desired)
      - type: tmpfs # IF needed
              target: /tmp
              tmpfs:
                  mode: 01777
    command:
      - "--op-token=file:/run/secrets/op_token"

[evoandroidevo]

Thanks for the detailed reply!

Ill test this out and see which ones works best for my needs, i kinda got around it by setting the user to default and using the gid that is needed for the application but it still has permission pains if the container starts with root and the app starts with another uid depending on how files are loaded for env.

locket:
    image: ghcr.io/bpbradley/locket:op
    user: "65532:1000"
    container_name: locket-auth
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    command:
      - "--provider=op"
      - "--mode=park"
      - "--inject-failure-policy=error"
      - "--log-level=info"
      - "--user=65532:1000"
      # -rw-r----- file mode
      - "--file-mode=0640"
      - "--dir-mode=0750"
      - "--op-token=file:/run/secrets/op_token"
    secrets:
      - op_token
    volumes:
      # Mount in your actual secret templates, with secret references
      # Mount in your output directory, where you want secrets materialized
      - secrets-store-auth:/run/secrets/locket

[bpbradley]

Thanks for the detailed reply!

Ill test this out and see which ones works best for my needs, i kinda got around it by setting the user to default and using the gid that is needed for the application but it still has permission pains if the container starts with root and the app starts with another uid depending on how files are loaded for env.

locket:
    image: ghcr.io/bpbradley/locket:op
    user: "65532:1000"
    container_name: locket-auth
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    command:
      - "--provider=op"
      - "--mode=park"
      - "--inject-failure-policy=error"
      - "--log-level=info"
      - "--user=65532:1000"
      # -rw-r----- file mode
      - "--file-mode=0640"
      - "--dir-mode=0750"
      - "--op-token=file:/run/secrets/op_token"
    secrets:
      - op_token
    volumes:
      # Mount in your actual secret templates, with secret references
      # Mount in your output directory, where you want secrets materialized
      - secrets-store-auth:/run/secrets/locket

Sounds good! That's another solution I'll add to the mix, I hadnt tried that. Glad you figured something out though.

One thing though, if you change it back to 1000:1000, the docker volume for secrets-store you have there may not be happy because it may have permissions automatically inherited from your container. I've run into that before in testing. If you have an issue, just nuke that volume so it gets recreared with correct permissions, or set it up with the explicit gui/uid.

[bpbradley]

Also just a couple nitpicks looking at your config, it is just fine as is, but, for awareness...

1. If you use the :op tag you actually don't need to select the provider. It is set in the image directly (and its the only provider source compiled into the binary). But being explicit is fine too and allows you to move to the all in one image if desired.
2. --user is harmless here, but it is not needed (and can't do anything) in sidecar mode with non-root user. The point of --user was when I added support for docker-volume driver (where locket is the actual provider for the docker daemon for volumes), as this service runs as root and it needs to create files for your volumes. So the --user flag allows the volume driver to create the files/folders in that volume with the specified ownership on the host OS (in a tmpfs). Otherwise it will create files with automatic ownership rules applied. This was just a way to allow explicit ownership on the volume in a familiar way.

So like this was the intention for user in options.

name: volume-demo
services:
    demo:
        user: 1000:1000
        image: busybox
        command:
            - "sh"
            - "-c"
            - "cat /run/secrets/locket/template && echo && sleep 120"
        volumes:
            - locket-volume-op:/run/secrets/locket:ro
  
volumes:
    locket-volume-op:
        driver: bpbradley/locket:plugin # Can use locket if installed with --alias locket
        driver_opts:
            user: 1000:1000 # folder on host OS will be created with these permissions.
            provider: op
            op-token: file:/etc/locket/tokens/op
            secret.template: "{{ op://Mordin/TestKey/private key?ssh-format=openssh }}"

But generally well done :)