Feature #47264

"fs authorize" subcommand should work for multiple FSs too

Added by Rishabh Dave about 1 year ago. Updated 3 months ago.

Fix Under Review
Target version:
% Done:


Affected Versions:
Common/Protocol, MDSMonitor
Labels (FS):
Pull request ID:


Currently assigning caps for a second FS to an already existing client (which holds caps for a different FS already) using "ceph fs authorize" subcommand is not possible -

$ ./bin/ceph fs ls
name: a, metadata pool: cephfs.a.meta, data pools: [ ]
name: cephfs2, metadata pool: cephfs2_meta, data pools: [cephfs2_data ]
$ ./bin/ceph fs authorize a client.someuser / rw
    key = AQAjeUNfcvezHhAAzFTLqmpzZRqgEV5bRReChw==
$ ./bin/ceph fs authorize cephfs2 client.someuser / rw
Error EINVAL: client.someuser already has fs capabilities that differ from those supplied. To generate a new auth key for client.someuser, first remove client.someuser from configuration files, execute 'ceph auth rm client.someuser', then execute this command again.

I think it would be very convenient for CephFS users to be able to assign caps for multiple FSs to already existing clients using this subcommand. Ticket #15070 (PR #32581) already adds the ability for a client to have caps for multiple FSs, we just need to modify behaviour for "fs authorize" subcommand to get this done.

Also, IMO, it would be nice to have the reverse of the behaviour proposed above: removing caps only for a certain FS for a client. We can add a new subcommand "fs deauthorize" the syntax of which would be same as that of "fs authorize".

Related issues

Related to CephFS - Feature #15070: mon: client: multifs: auth caps on client->mon connections to limit their access to MDSMaps by FSCID Resolved


#1 Updated by Rishabh Dave about 1 year ago

  • Related to Feature #15070: mon: client: multifs: auth caps on client->mon connections to limit their access to MDSMaps by FSCID added

#2 Updated by Patrick Donnelly about 1 year ago

  • Target version set to v16.0.0
  • Source set to Development

#3 Updated by Patrick Donnelly 8 months ago

  • Target version changed from v16.0.0 to v17.0.0

#4 Updated by Rishabh Dave 5 months ago

  • Status changed from New to In Progress

#5 Updated by Rishabh Dave 3 months ago

  • Status changed from In Progress to Fix Under Review
  • Pull request ID set to 41779

Also available in: Atom PDF