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@ceph.io wrote:

Send ceph-users mailing list submissions to ceph-users@ceph.io

To subscribe or unsubscribe via email, send a message with subject or body 'help' to ceph-users-request@ceph.io

You can reach the person managing the list at ceph-users-owner@ceph.io

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@ceph.io To unsubscribe send an email toceph-users-leave@ceph.io %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s