Hi Eugen,
Thank you for a viable solution to our underlying issue - I'll attempt
to implement it shortly. :-)
However, with all the respect in world, I believe you are incorrect when
you say the doco is correct (but I will be more than happy to be proven
wrong). :-)
The relevant text (extracted from the document page (the last couple of
paragraphs)) says:
~~~
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:
cephfsauthorizeaclient.x/dir1rw
cephauthgetclient.x
[client.x]
key = AQC1tyVknMt+JxAAp0pVnbZGbSr/nJrmkMNKqA==
caps mds = "allow rw fsname=a path=/dir1"
caps mon = "allow r fsname=a"
caps osd = "allow rw tag cephfs data=a"
cephfsauthorizeaclient.x/dir2rw
updated caps for client.x
cephauthgetclient.x
[client.x]
key = AQC1tyVknMt+JxAAp0pVnbZGbSr/nJrmkMNKqA==
caps mds = "allow rw fsname=a path=dir1, allow rw fsname=a path=dir2"
caps mon = "allow r fsname=a"
caps osd = "allow rw tag cephfs data=a"
~~~
The above *seems* to me to say (as per the 2nd `cephauthgetclient.x`
example) that a 2nd directory (dir2) *will* be added to the `client.x`
authorisation.
HOWEVER, this does not work in practice - hence my original query.
This is what we originally attempted to do (word for word, only
substituting our CechFS name for "a") and we got the error in the
original post.
So if the doco says that something can be done *and* gives a working
example, but an end-user (admin) cannot achieve the same results but
gets an error instead when following the exact same commands, then
either the doco is incorrect *or* there is something else wrong.
BUT your statement ("running 'ceph fs authorize' will overwrite the
existing caps, it will not add more caps to the client") is in direct
contradiction to the documentation ("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").
So there's some sort of "disconnect" there. :-)
Cheers
On 24/04/2024 17:33, ceph-users-request@xxxxxxx wrote:
Send ceph-users mailing list submissions to
ceph-users@xxxxxxx
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
ceph-users-request@xxxxxxx
You can reach the person managing the list at
ceph-users-owner@xxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ceph-users digest..."
Today's Topics:
1. Re: Latest Doco Out Of Date? (Eugen Block)
2. Re: stretched cluster new pool and second pool with nvme
(Eugen Block)
3. Re: Latest Doco Out Of Date? (Frank Schilder)
_______________________________________________
ceph-users mailing list --ceph-users@xxxxxxx
To unsubscribe send an email toceph-users-leave@xxxxxxx
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
