Docker (compose) Permission denied

Thank you so much for thinking along and giving a lot of things a try!

I tried to play around a bit with your last suggestion. Also, instead of using the 'Shared Folder' as the root-folder I created a folder in the Shared Folder and run from this one. Perhaps Synology/Docker treats a Shared Folder a bit different as well.

Unfortunately all end up with a:

Error: Server: (failed to OpenDefault), Wrapped: (failed to defaultPath), failed to ConfigDir: Can't continue. We can't safely access "/home/opuser/.op" because it's not owned by the current user. Change the owner or logged in user and try again.

I guess my (our ;) ) 'quest' ends here as I do have a working work-around/solution. Thanks a lot for your awesome support!

I guess 1password still has some hard-coded user-config .. :) ?

That's also what I thought, but I checked the code and that is not the case. The check uses the ID of the user that is running the process. So that should be 1042.

One final idea, is that the root of the mountpoint gets treated differently by Docker. If that is the case, changing the mount to - "./:/home/opuser/" might work. That is something you could try for educational purposes, as you've already gotten it to work :)

Just for the sake of testing, I tested with this compose-file:

version: "3.4"

services:
op-connect-api:
image: 1password/connect-api:latest
user: "1042"
ports:
- "8888:8080"
volumes:
- "./:/home/opuser/.op"
environment:
XDG_DATA_HOME: "/home/opuser/"
op-connect-sync:
image: 1password/connect-sync:latest
user: "1042"
volumes:
- "./:/home/opuser/.op"
environment:
XDG_DATA_HOME: "/home/opuser/"

In combination with sudo chown -R 1042 1password to make sure the user 1042 is indeed the owner of the main folder and all of it's children. This results in the following:

Error: Server: (failed to OpenDefault), Wrapped: (failed to defaultPath), failed to ConfigDir: Can't continue. We can't safely access "/home/opuser/.op" because it's not owned by the current user. Change the owner or logged in user and try again.

I guess 1password still has some hard-coded user-config .. :) ?

I recreated the host folder from scratch, leaving root as the owner. I give usergroup 'SYSTEM' (id 1 I believe) access and left the user: "1042" out of the docker-compose, basically reverting back to the example provided from 1Password. This actually does work! ... ? What I am not 100% of, is whether this is any safe ...

That's interesting and good to hear! I am inclined to say that that should be okay. Your main concern should be whether other users can access the directory (especially the credentials file) when accessing your NAS. I know too little about Synology or the exact setup to give a definitive answer, but but my feeling is that giving SYSTEM access should not be a problem. In fact, I'd expect that user to always have had access.

For what it is still worth, the most recent logs seem to point at the same problem as https://1password.community/discussion/comment/628495/#Comment_628495.

Terminal screenshot from the host:

Terminal screenshot from within the container:

Showing that the folder are indeed owned by 1042, Unfortunately, still:

Error: Server: (failed to OpenDefault), Wrapped: (failed to open db), unable to open database file: no such file or directory
{"log_message":"(W) configured to use HTTP with no TLS","timestamp":"2022-02-10T11:27:18.774745586Z","level":2}
{"log_message":"(I) no existing database found, will initialize at /.op/data/1password.sqlite","timestamp":"2022-02-10T11:27:18.77517923Z","level":3}
{"log_message":"(I) [discovery-local] starting discovery, advertising endpoint 36900 /meta/message","timestamp":"2022-02-10T11:27:18.77483875Z","level":3}
{"log_message":"(I) starting 1Password Connect Sync ...","timestamp":"2022-02-10T11:27:18.776127624Z","level":3}
{"log_message":"(I) serving on :8080","timestamp":"2022-02-10T11:27:18.776165348Z","level":3}
Usage:
connect-sync [flags]

Flags:
-h, --help help for connect-sync
-v, --version version for connect-sync

and

{"log_message":"(I) no database found, will retry in 1s","timestamp":"2022-02-10T11:27:19.263556135Z","level":3}
{"log_message":"(I) no database found, will retry in 1s","timestamp":"2022-02-10T11:27:20.264476045Z","level":3}
{"log_message":"(I) no database found, will retry in 1s","timestamp":"2022-02-10T11:27:21.265010184Z","level":3}
{"log_message":"(I) no database found, will retry in 1s","timestamp":"2022-02-10T11:27:22.265173906Z","level":3}

I did have some other findings though:
I recreated the host folder from scratch, leaving root as the owner. I give usergroup 'SYSTEM' (id 1 I believe) access and left the user: "1042" out of the docker-compose, basically reverting back to the example provided from 1Password. This actually does work! ... ? What I am not 100% of, is whether this is any safe ...

Just to be sure, is this what you meant with your first suggestion?:

Yes. Assuming that ./ is owned by user 1042 in the Synology interface.

Using:
entrypoint: ["/bin/sh", "-c", "chown -R 1042 /home/opuser/.op && connect-api"]
Gives:

op-connect-api_1 | chown: cannot read directory '/home/opuser/.op': Permission denied

Using
entrypoint: ["/bin/sh", "-c", "sudo chown -R 1042 /home/opuser/.op && connect-api"]
Gives:

op-connect-api_1 | /bin/sh: 1: sudo: not found

Just to be sure, is this what you meant with your first suggestion?:
```
version: "3.4"

services:
op-connect-api:
image: 1password/connect-api:latest
user: "1042"
ports:
- "8888:8080"
volumes:
- "./:/home/opuser/.op"
op-connect-sync:
image: 1password/connect-sync:latest
user: "1042"
volumes:
- "./:/home/opuser/.op"
```

The folders are very specifically created by user opuser. No matter how I mount my volumes (- "data:..." or - "./data:...") I will keep having mismatched between the docker user and the host/folder. Do you agree with my findings? If so, what could we do to work around it :)

I think you're right here. Though that also suggests an alternative solution: what if you replace both volume mounts with this one: ./:/home/opuser/.op (make sure the 1password-credentials.json file is in ./). With a bit of luck, that works because the /home/opuser/.op is then owned by user 1042.

Alternatively, it is possible to execute a command during startup by modifying the entrypoint of one of the containers:

entrypoint: ["/bin/sh", "-c", "echo 'This text gets printed during startup' && connect-api"]

or

entrypoint: ["/bin/sh", "-c", "echo 'This text gets printed during startup' && connect-sync"]


One final thing worth checking: is it possible to choose which ID gets assigned to the user you create in the Synology software? If so, could you create one with ID 999?

One of the problems is, when using the - "data:.." volume mount, the containers exit before I can exec into them to do chown:

op-connect-sync_1 | {"log_message":"(W) configured to use HTTP with no TLS","timestamp":"2022-02-10T07:46:10.515989241Z","level":2}
op-connect-sync_1 | {"log_message":"(I) [discovery-local] starting discovery, advertising endpoint 43507 /meta/message","timestamp":"2022-02-10T07:46:10.516746882Z","level":3}
op-connect-sync_1 | Error: Server: (failed to OpenDefault), Wrapped: (failed to defaultPath), failed to ConfigDir: Can't continue. We can't safely access "/home/opuser/.op" because it's not owned by the current user. Change the owner or logged in user and try again.
op-connect-sync_1 | {"log_message":"(I) starting 1Password Connect Sync ...","timestamp":"2022-02-10T07:46:10.518789319Z","level":3}
op-connect-sync_1 | {"log_message":"(I) serving on :8080","timestamp":"2022-02-10T07:46:10.518843407Z","level":3}
op-connect-sync_1 | Usage:
op-connect-sync_1 | connect-sync [flags]
op-connect-sync_1 |
op-connect-sync_1 | Flags:
op-connect-sync_1 | -h, --help help for connect-sync
op-connect-sync_1 | -v, --version version for connect-sync
op-connect-sync_1 |
1password_op-connect-sync_1 exited with code 0

This gives me no time to run any command unfortunately.