Hi,
I believe the docs [2] are okay, running 'ceph fs authorize' will
overwrite the existing caps, it will not add more caps to the client:
Capabilities can be modified by running fs authorize only in the
case when read/write permissions must be changed.
If a client already has a capability for file-system name a and path
dir1, running fs authorize again for FS name a but path dir2,
instead of modifying the capabilities client already holds, a new
cap for dir2 will be granted
To add more caps you'll need to use the 'ceph auth caps' command, for example:
quincy-1:~ # ceph fs authorize cephfs client.usera /dir1 rw
[client.usera]
key = AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw==
quincy-1:~ # ceph auth get client.usera
[client.usera]
key = AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw==
caps mds = "allow rw fsname=cephfs path=/dir1"
caps mon = "allow r fsname=cephfs"
caps osd = "allow rw tag cephfs data=cephfs"
quincy-1:~ # ceph auth caps client.usera mds 'allow rw fsname=cephfs
path=/dir1, allow rw fsname=cephfs path=/dir2' mon 'allow r
fsname=cephfs' osd 'allow rw tag cephfs data=cephfs'
updated caps for client.usera
quincy-1:~ # ceph auth get client.usera
[client.usera]
key = AQDOrShmk6XhGxAAwz07ngr0JtPSID06RH8lAw==
caps mds = "allow rw fsname=cephfs path=/dir1, allow rw
fsname=cephfs path=/dir2"
caps mon = "allow r fsname=cephfs"
caps osd = "allow rw tag cephfs data=cephfs"
Note that I don't actually have these directories in that cephfs, it's
just to demonstrate, so you'll need to make sure your caps actually
work.
Thanks,
Eugen
[2]
https://docs.ceph.com/en/latest/cephfs/client-auth/#changing-rw-permissions-in-caps
Zitat von Zac Dover <zac.dover@xxxxxxxxx>:
It's in my list of ongoing initiatives. I'll stay up late tonight
and ask Venky directly what's going on in this instance.
Sometime later today, I'll create an issue tracking bug and I'll
send it to you for review. Make sure that I haven't misrepresented
this issue.
Zac
On Wednesday, April 24th, 2024 at 2:10 PM, duluxoz <duluxoz@xxxxxxxxx> wrote:
Hi Zac,
Any movement on this? We really need to come up with an
answer/solution - thanks
Dulux-Oz
On 19/04/2024 18:03, duluxoz wrote:
Cool!
Thanks for that :-)
On 19/04/2024 18:01, Zac Dover wrote:
I think I understand, after more thought. The second command is
expected to work after the first.
I will ask the cephfs team when they wake up.
Zac Dover
Upstream Docs
Ceph Foundation
On Fri, Apr 19, 2024 at 17:51, duluxoz
<[duluxoz@xxxxxxxxx](mailto:On Fri, Apr 19, 2024 at 17:51,
duluxoz <<a href=)> wrote:
Hi All,
In reference to this page from the Ceph documentation:
https://docs.ceph.com/en/latest/cephfs/client-auth/, down the bottom of
that page it says that you can run the following commands:
~~~
ceph fs authorize a client.x /dir1 rw
ceph fs authorize a client.x /dir2 rw
~~~
This will allow `client.x` to access both `dir1` and `dir2`.
So, having a use case where we need to do this, we are, HOWEVER, getting
the following error on running the 2nd command on a Reef 18.2.2 cluster:
`Error EINVAL: client.x already has fs capabilities that differ from
those supplied. To generate a new auth key for client.x, first remove
client.x from configuration files, execute 'ceph auth rm client.x', then
execute this command again.`
Something we're doing wrong, or is the doco "out of date" (mind you,
that's from the "latest" version of the doco, and the "reef" version),
or is something else going on?
Thanks in advance for the help
Cheers
Dulux-Oz
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
