- ceph-users - lists.ceph.io

Re: mgmt-gateway - Issue with Prometheus/Alertmanager mTLS
by Redouane Kachach 23 Jun '26

23 Jun '26

Hi Cameron, I'd recommend using the slack channel and posting more info about the kind of errors you are getting. Regards, Redo. On Fri, Jun 19, 2026 at 12:47 PM Cameron Ditchfield via ceph-users < ceph-users(a)ceph.io> wrote: > Hi ! > > Has anyone running Tentacle successfully got the management gateway working > with a non-cephadm-root issued certificate? > > I'm struggling to get it working with Prometheus & Alertmanager when using > a cert not issued by the cephadm-root CA. I have a Tentacle cluster v20.2.1 > that has the management gateway deployed across three nodes with a > keepalived ingress and virtual IP. I've updated the dashboard to point to > the DNS hostname for the VIP for alertmanager and prometheus. > > I can access the dashboard via the hostname, as expected, but there are no > metrics on the overview page and there's a cannot verify SSL cert error for > both alertmanager and prometheus. The CA that issued the gateway cert is > trusted by all nodes in the cluster. > > Thanks, > Cameron > > -- > Thought Machine Group Limited, a company registered in England & Wales. > Registered number: 11114277. > Registered Office: 5 New Street Square, > London EC4A 3TW > < > https://maps.google.com/?q=5+New+Street+Square,+London+EC4A+3TW&entry=gmail… > >. > > > The content of this email is confidential and intended for the recipient > specified in message only. It is strictly forbidden to share any part of > this message with any third party, without a written consent of the > sender. > If you received this message by mistake, please reply to this message and > follow with its deletion, so that we can ensure such a mistake does not > occur in the future. > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > >

1 0

OSD don't ant to start
by Gilles Mocellin 23 Jun '26

23 Jun '26

Hello, After removing a failing drive with : ceph orch osd rm ${ID} --zap --replace Waiting for recovery (3 days, in a 12 nodes 144 drives)... I add the drive with : ceph orch daemon add osd myserver:/dev/sdn In the journal logs of the OSD, I can see : Jun 23 10:06:51 myserver bash[1944632]: debug 2026-06-23T08:06:51.908+0000 7f1fffa90740 1 osd.66 389707 start_boot Jun 23 10:06:51 myserver bash[1944632]: debug 2026-06-23T08:06:51.908+0000 7f1fffa90740 1 osd.66 389707 maybe_override_options_for_qos osd_max_backfills set to 1 Jun 23 10:06:51 myserver bash[1944632]: debug 2026-06-23T08:06:51.912+0000 7f1fffa90740 1 osd.66 389707 maybe_override_options_for_qos osd_recovery_max_active set to 0 Jun 23 10:06:51 myserver bash[1944632]: debug 2026-06-23T08:06:51.912+0000 7f1fffa90740 1 osd.66 389707 maybe_override_options_for_qos osd_recovery_max_active_hdd set to 3 Jun 23 10:06:51 myserver bash[1944632]: debug 2026-06-23T08:06:51.912+0000 7f1fffa90740 1 osd.66 389707 maybe_override_options_for_qos osd_recovery_max_active_ssd set to 10 Jun 23 10:06:51 myserver bash[1944632]: debug 2026-06-23T08:06:51.912+0000 7f1fffa90740 1 osd.66 389707 bench count 12288000 bsize 4 KiB Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.552+0000 7f1fffa90740 1 osd.66 389707 maybe_override_max_osd_capacity_for_qos osd bench result - bandwidth (MiB/sec): 6.518 iops: 1668.622 elapsed_sec: 1.798 Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.552+0000 7f1fffa90740 0 log_channel(cluster) log [WRN] : OSD bench result of 1668.621657 IOPS is not within the threshold limit range of 50.000000 IOPS and 500.000000 IOPS for osd.66. IOPS capacity is unchanged at 315.000000 IOPS. The recommendation is to establish the osd's IOPS capacity using other benchmark tools (e.g. Fio) and then override osd_mclock_max_capacity_iops_[hdd|ssd]. Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.552+0000 7f1ffba10640 -1 osd.66 389707 osdmap says I am destroyed Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.740+0000 7f1fef00a640 -1 osd.66 389747 map says i am stopped by admin. shutting down. Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.740+0000 7f1fef00a640 0 osd.66 389747 _committed_osd_maps shutdown OSD via async signal Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.740+0000 7f1ffca28640 -1 received signal: Interrupt from Kernel ( Could be generated by pthread_kill(), raise(), abort(), alarm() ) UID: 0 Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.740+0000 7f1ffca28640 -1 osd.66 389747 *** Got signal Interrupt *** Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.740+0000 7f1ffca28640 0 osd.66 389747 Fast Shutdown: - cct->_conf->osd_fast_shutdown = 1, null-fm = 0 Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.740+0000 7f1ffca28640 -1 osd.66 389747 *** Immediate shutdown (osd_fast_shutdown=true) *** Jun 23 10:06:55 myserver bash[1944632]: debug 2026-06-23T08:06:55.740+0000 7f1ffca28640 0 osd.66 389747 prepare_to_stop starting shutdown Jun 23 10:06:57 myserver systemd[1]: ceph-02acb271-d31a-4c26-82a2-0e0e1c579ed5(a)osd.66.service: Deactivated successfully. I retry several time, nothing new. The OSD is mark down and then stops. I've found that solution on RedHat site : https://access.redhat.com/solutions/7029908 Which is related to epochs, they have that log before : 276003 handle_osd_map epochs [276004,276043] i have 276003, src has [274883, 303268] 276043 map says i am stopped by admin. shutting down. I don't have messages about epochs. I tried anyway with thoses settings : # ceph config set osd osd_map_message_max 1000 # ceph config set osd osd_map_share_max_epochs 1000 But no, the OSD still doesn't start. Has anyone a clue ?

1 0

Re: Ceph Scrub Schedule
by Eugen Block 23 Jun '26

23 Jun '26

Hi, I'm not aware of any more granular approach. Until a few years ago we used a deep-scrub script via cronjob to configure a ratio we wanted to deep-scrub during a specific time window. During weekends the amount of deep-scrubs was higher than on work days. Back then we had a HDD cluster with a cache-tier on SSD and we needed the performance during working hours. This thread contains some form of it, I think there are several versions of it online: https://forum.proxmox.com/threads/ceph-schedule-deep-scrubs-to-prevent-serv… We upgraded to (almost) all flash in the meantime so we're not that sensitive anymore to the deep-scrub workload. Regards, Eugen Zitat von Alex via ceph-users <ceph-users(a)ceph.io>: > Hello everyone. > > We've been having issues with Deep Scrubs interfering with Ceph-backed VM > performance. > Hardware upgrade is unfortunately out of the question for now. > After much experimenting, asking and searching we've settled on cutting the > scrubs during the weekday hours which is when the deploys happen to a > couple of hours a night and letting the scrubs run for almost the entire > day during the weekend to catch up. There are still missed scrubs by the > EOW but i manually trigger them. It's not great but it works. > > The way we do this is a cron job which changes the schedule on Friday night > and sets it back on Sunday. > > For example > Mon-Fri deep scrub 1am-4am > Sat-Sun deep scrub 1am-11pm > > The first question is there's nothing else i assume we can tweak? The > consecutive scrubs are already set to one, we can't upgrade the hardware, > we tried various scrub windows and just can't fit them in during the > weekdays without the cron job hack. Is there something obvious we missed? > > The second question is, is there really no more granular schedule then > hours during which the deep scrub can run? The cron feels like a dirty hack. > > There's the "osd_scrub_begin/end_week_day" setting but that doesn't do what > we need. > We want to do some scrubs during the week and the rest during the weekend. > > Thanks. > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Next Ceph Users & Devs Meetup Wednesday, June 24th, at 7 am PDT
by Anthony Middleton 22 Jun '26

22 Jun '26

Hey Ceph Friends, I hope your week is off to a good start. The next Ceph Users + Devs Meetup is this Wednesday, June 24th, at 7 am PDT. If you'd like to add a topic to the agenda, there's still time. Please add topics to the pad before Tuesday evening so the host has time to review in advance. Ether Pad link - https://pad.ceph.com/p/ceph-user-dev-monthly-minutes If you have any questions, please let me know. Best, ------- Anthony Middleton Community Manager, Ceph Foundation amiddleton(a)linuxfoundation.org LinkedIn <https://www.linkedin.com/company/ceph>| BlueSky <https://bsky.app/profile/ceph.io> | Twitter <https://x.com/Ceph>

1 0

CSC Meeting Notes: 2026-06-22
by Adam Emerson 22 Jun '26

22 Jun '26

Ceph Steering Committee Meeting Notes 22 June 2026 * Dan van der Ster: Voting rules discussion/reminder* ** Patrick had kicked off doing Robert's rules of order/Helios ** Last week two motions didn't pass because we didn't have enough votes *** We need to be a bit more tactical. *** We have 34 voting members *** We adopted the technical charter with the voting rules ** There's two thresholds *** We need to have a quorum (50%) we just need a majority to pass a motion (we could have nine people in favor) *** We currently have a quorum, and we're mostly voting members. *** For electronic votes we always need at least 50% of voting members. ** Regarding adding and removing members *** There was no text about that in the new technical charter *** In our governance charter we require a supermajority rule *** The project can come up with its own rule/process for adding/removing members. ** The intuitive/obvious thing is we grandfather in the supermajority rule for adding members *** Last week we had two motions on the floor, one to add Sage McTaggart *** One is to require the security working group, and that should require a majority ** The Helios vote should be out right now *** It should be open now, and should have opened just at the start of this meeting. ** Joseph M: Do we need a vote to create working groups? *** We didn't need a vote to make the Cephalocon working groups, but we decided to have one for the security working group. *** Maybe it's case by case and depends on the function. * Dan van der Ster: Do we want to encourage people to come to this meeting so we get quorum? ** Adam E: Yes. * Neha: Ceph day London update ** IBM and Canonical were the sponsors ** Lots of poeple using Ceph showed up, interesting talks ** New presentations of things landing soon and projects people are building with Ceph. ** It was very successful and this is one geographic area where community events are clearly shining. ** Photos will be uploaded soon. * Cephalocon working group kickoff ** https://tracker.ceph.com/issues/77296 ** Coordinating over Slack * There is a Foundation board meeting tomorrow ** Neha will present feedback from us to the Foundation * The meeting was posed for everyone to vote in Helios so we can get it done * Neja: Anthony Middleton brought it to our notice that we don't have a component lead for NVMEof ** Earlier we had the concept of a component lead being a member of the CSC by default ** Motion that we add Aviv made by Neha and seconded by Yehuda *** Added to a Helios vote

1 0

Ceph Scrub Schedule
by Alex 22 Jun '26

22 Jun '26

Hello everyone. We've been having issues with Deep Scrubs interfering with Ceph-backed VM performance. Hardware upgrade is unfortunately out of the question for now. After much experimenting, asking and searching we've settled on cutting the scrubs during the weekday hours which is when the deploys happen to a couple of hours a night and letting the scrubs run for almost the entire day during the weekend to catch up. There are still missed scrubs by the EOW but i manually trigger them. It's not great but it works. The way we do this is a cron job which changes the schedule on Friday night and sets it back on Sunday. For example Mon-Fri deep scrub 1am-4am Sat-Sun deep scrub 1am-11pm The first question is there's nothing else i assume we can tweak? The consecutive scrubs are already set to one, we can't upgrade the hardware, we tried various scrub windows and just can't fit them in during the weekdays without the cron job hack. Is there something obvious we missed? The second question is, is there really no more granular schedule then hours during which the deep scrub can run? The cron feels like a dirty hack. There's the "osd_scrub_begin/end_week_day" setting but that doesn't do what we need. We want to do some scrubs during the week and the rest during the weekend. Thanks.

1 0

Re: Advice needed: CephFS PGs down/unknown after several OSDs failure — implications on marking OSDs lost
by Sergio Rabellino 22 Jun '26

22 Jun '26

I'm not the best choice for a safe answer, but probably you should also declare the pools replica/erasure configuration and what is the domain failure choice: in my experience losing a node should not bring to pg unknown. Anyway I suggest to first understand why this happened and try to bring all the pg to a clean state, before doing any other action on upper layers. Bests. Il 22/06/2026 12:46, Alessandro De Salvo via ceph-users ha scritto: > > Dear ceph-users, > > we are looking for an advice before taking any destructive action on a > production Ceph cluster (18.2.4) after a SAN failure. > > We lost access to a Disk System hosting several OSDs. The bulk of the > recovery/backfills did complete, and most PGs are now `active+clean`, > but a small set of PGs remains in status `unavailable`. The Disk > System might still be recoverable, but not easily or quickly; it may > take days, or it may never come back. We are trying to understand the > risk of waiting versus marking the missing OSDs as lost. > > We have not marked any OSDs as lost yet. > > This is a Ceph Reef cluster, version 18.2.4. > > Sanitized current status: > > health: HEALTH_WARN > 1 filesystem is degraded > 1 MDS reports slow metadata IOs > noscrub,nodeep-scrub flags set > (temporarily enabled by us to reduce scrub load during > recovery/rebalancing) > Reduced data availability: 28 PGs inactive, 12 PGs down > slow ops still present > osd: > 86 OSDs total > 69 up/in > 17 OSDs unavailable because of the SAN issue > pgs: > 3320 active+clean > 16 unknown > 11 down > 1 down+remapped > > The problematic PGs are spread across several services/pools: > > Main CephFS data pool: 4 PGs down > Secondary CephFS metadata/data: 1 metadata PG unknown, 4 data PGs unknown > RGW/S3 service A: 2 bucket-data PGs down + 1 metadata PG unknown > RGW/S3 service B: 5 mostly empty bucket-data PGs down + 1 metadata PG > unknown > RBD/Kubernetes: 1 PG unknown > > The services we care about most are the filesystems, especially the > main CephFS and the secondary CephFS. > > For the main CephFS, the metadata pool does not appear to have > inactive PGs. The remaining problematic PGs are in the data pool. Of > the main CephFS data PGs, only one appears to contain real data; the > others appear empty. > > For the non-empty main CephFS data PG, `pg query` shows roughly: > > state: down > acting/up: all current acting OSDs are up > last_update == last_complete > empty: 0 > incomplete: 0 > stat_sum: > num_bytes: ~80 GB > num_objects: ~131k > num_objects_missing: 0 > num_objects_unfound: 0 > num_objects_degraded: 0 > num_objects_misplaced: 0 > blocked: > peering is blocked due to down OSDs > down_osds_we_would_probe: > a few OSDs from previous intervals > peering_blocked_by: > "starting or marking this osd lost may let us proceed" > > The recovery state for this PG includes past intervals with OSDs that > are currently unavailable. The current acting set is up, but Ceph > refuses to activate the PG because it still wants to probe down OSDs > from the PG history. > > We tried to list objects from that PG: > rados -p <main_cephfs_data_pool> ls --pgid <pgid> > > but it hangs/times out, so we cannot currently map RADOS objects back > to CephFS inode/path names. > > For the secondary CephFS, the situation is more concerning because one > metadata PG is `unknown`. Most `pg query` attempts on unknown PGs return: > Error ENOENT: i don't have pgid <pgid> > > For the RGW/S3 pools, a couple of bucket-data PGs are non-empty and > down, while some others appear empty. Some metadata PGs are unknown. > RGW can temporarily work after restarting daemons, but eventually gets > stuck again, presumably when requests hit unavailable RADOS objects or > metadata. > > We also tested some RBD/Kubernetes volumes. For the Kubernetes RBD > pool, only one non-critical PVC seems to hang on `rbd info`; most > other images respond. So the main operational concern remains CephFS > and RGW. > > Our questions are: > 1. In a case like this, where a CephFS data PG is `down`, not > `incomplete`, and shows `num_objects_missing = 0` and > `num_objects_unfound = 0`, but peering is blocked by historical down > OSDs, what are the likely consequences of marking those OSDs as lost? > > 2. If we mark the unavailable OSDs as lost, should we expect the main > CephFS to: > - come back with only some files or file extents unreadable/corrupt, > - remain blocked/degraded, > - or risk a wider filesystem-level failure? > > 3. Since the main CephFS metadata pool does not appear to have > inactive PGs, is it reasonable to assume that the risk is mostly > limited to file data objects rather than the entire namespace? Or is > that assumption unsafe? > > 4. For the secondary CephFS, where a metadata PG is `unknown`, should > we treat declaring OSDs lost as much more dangerous? Could that make > the whole filesystem unusable rather than only losing some files? > > 5. Is there any recommended way to map the affected CephFS data PG to > file paths while the PG is still down? `rados ls --pgid` hangs, so we > currently cannot list objects in the PG. > > 6. Before declaring the unavailable OSDs lost, are there any > additional diagnostic or recovery steps you would recommend to better > assess the situation or reduce the risk of data loss? > > Any advice would be greatly appreciated. > > Best regards, > > Nadir and Alessandro > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > -- ing. Sergio Rabellino Università degli Studi di Torino Dipartimento di Informatica Tecnico di Ricerca Cel +39-342-529-5409 Tel +39-011-670-6701 Fax +39-011-751603 C.so Svizzera , 185 - 10149 - Torino <http://www.di.unito.it>

1 0

Re: Query regarding Debian Trixie support for Squid and Tentacle
by BASSAGET Cédric 22 Jun '26

22 Jun '26

Hello I think ceph team prefers to maintain quay.io images for containers as they are pushing up cephadm as replacement of legacy clusters. I'm currentrly running an old legacy cluster on debian 12 / ceph 18 and I'm stuck with a python problem (a known pyo3 issue). Trying to move to cephadm but can't load cephadm module because of this pyo3 issue. I'm wayting for a fix / tip / workaround .... Regards Cédric Le ven. 19 juin 2026 à 12:19, Piradeep G via ceph-users <ceph-users(a)ceph.io> a écrit : > Hi everyone, > > I have a question regarding package availability for Debian Trixie. > > Currently, I can see that the Debian-Squid packages are available only for > the Bookworm and Jammy distributions. Are there any plans to provide > Debian-Squid packages for Debian Trixie as well? > > Similarly, I noticed that the Debian-Tentacle packages are currently > available only for Bookworm, Jammy, and Noble. Is support for Debian Trixie > planned for Debian-Tentacle, and if so, is there an estimated timeline for > when it will be available? > > We're evaluating our upgrade plans and would appreciate any information or > insights from the community. > > Thanks in advance! > > Regards, > > Piradeep G > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io >

1 0

Advice needed: CephFS PGs down/unknown after several OSDs failure — implications on marking OSDs lost
by Alessandro De Salvo 22 Jun '26

22 Jun '26

Dear ceph-users, we are looking for an advice before taking any destructive action on a production Ceph cluster (18.2.4) after a SAN failure. We lost access to a Disk System hosting several OSDs. The bulk of the recovery/backfills did complete, and most PGs are now `active+clean`, but a small set of PGs remains in status `unavailable`. The Disk System might still be recoverable, but not easily or quickly; it may take days, or it may never come back. We are trying to understand the risk of waiting versus marking the missing OSDs as lost. We have not marked any OSDs as lost yet. This is a Ceph Reef cluster, version 18.2.4. Sanitized current status: health: HEALTH_WARN 1 filesystem is degraded 1 MDS reports slow metadata IOs noscrub,nodeep-scrub flags set (temporarily enabled by us to reduce scrub load during recovery/rebalancing) Reduced data availability: 28 PGs inactive, 12 PGs down slow ops still present osd: 86 OSDs total 69 up/in 17 OSDs unavailable because of the SAN issue pgs: 3320 active+clean 16 unknown 11 down 1 down+remapped The problematic PGs are spread across several services/pools: Main CephFS data pool: 4 PGs down Secondary CephFS metadata/data: 1 metadata PG unknown, 4 data PGs unknown RGW/S3 service A: 2 bucket-data PGs down + 1 metadata PG unknown RGW/S3 service B: 5 mostly empty bucket-data PGs down + 1 metadata PG unknown RBD/Kubernetes: 1 PG unknown The services we care about most are the filesystems, especially the main CephFS and the secondary CephFS. For the main CephFS, the metadata pool does not appear to have inactive PGs. The remaining problematic PGs are in the data pool. Of the main CephFS data PGs, only one appears to contain real data; the others appear empty. For the non-empty main CephFS data PG, `pg query` shows roughly: state: down acting/up: all current acting OSDs are up last_update == last_complete empty: 0 incomplete: 0 stat_sum: num_bytes: ~80 GB num_objects: ~131k num_objects_missing: 0 num_objects_unfound: 0 num_objects_degraded: 0 num_objects_misplaced: 0 blocked: peering is blocked due to down OSDs down_osds_we_would_probe: a few OSDs from previous intervals peering_blocked_by: "starting or marking this osd lost may let us proceed" The recovery state for this PG includes past intervals with OSDs that are currently unavailable. The current acting set is up, but Ceph refuses to activate the PG because it still wants to probe down OSDs from the PG history. We tried to list objects from that PG: rados -p <main_cephfs_data_pool> ls --pgid <pgid> but it hangs/times out, so we cannot currently map RADOS objects back to CephFS inode/path names. For the secondary CephFS, the situation is more concerning because one metadata PG is `unknown`. Most `pg query` attempts on unknown PGs return: Error ENOENT: i don't have pgid <pgid> For the RGW/S3 pools, a couple of bucket-data PGs are non-empty and down, while some others appear empty. Some metadata PGs are unknown. RGW can temporarily work after restarting daemons, but eventually gets stuck again, presumably when requests hit unavailable RADOS objects or metadata. We also tested some RBD/Kubernetes volumes. For the Kubernetes RBD pool, only one non-critical PVC seems to hang on `rbd info`; most other images respond. So the main operational concern remains CephFS and RGW. Our questions are: 1. In a case like this, where a CephFS data PG is `down`, not `incomplete`, and shows `num_objects_missing = 0` and `num_objects_unfound = 0`, but peering is blocked by historical down OSDs, what are the likely consequences of marking those OSDs as lost? 2. If we mark the unavailable OSDs as lost, should we expect the main CephFS to: - come back with only some files or file extents unreadable/corrupt, - remain blocked/degraded, - or risk a wider filesystem-level failure? 3. Since the main CephFS metadata pool does not appear to have inactive PGs, is it reasonable to assume that the risk is mostly limited to file data objects rather than the entire namespace? Or is that assumption unsafe? 4. For the secondary CephFS, where a metadata PG is `unknown`, should we treat declaring OSDs lost as much more dangerous? Could that make the whole filesystem unusable rather than only losing some files? 5. Is there any recommended way to map the affected CephFS data PG to file paths while the PG is still down? `rados ls --pgid` hangs, so we currently cannot list objects in the PG. 6. Before declaring the unavailable OSDs lost, are there any additional diagnostic or recovery steps you would recommend to better assess the situation or reduce the risk of data loss? Any advice would be greatly appreciated. Best regards, Nadir and Alessandro

1 0

pyo3 problem
by BASSAGET Cédric 22 Jun '26

22 Jun '26

Hello I first saw this problem about 2 years ago on ceph cluster (upgraded from 14 ... to 18) https://tracker.ceph.com/issues/64213 I'm unable to load cephadm module because of "ImportError: PyO3 modules may only be initialized once per interpreter process" error I tried to remove restful and nfs modules but they are still in the mgr config : # ceph daemon mgr.ceph-pa2-2 config show | grep -i modules "mgr_disabled_modules": "", "mgr_initial_modules": "restful iostat nfs", "mgr_standby_modules": "false", and I can't modify this key. I think it's in the ceph global config set by a previous ceph version (nothing in ceph.conf) # ceph-conf -D | grep module mgr_disabled_modules = mgr_initial_modules = restful iostat nfs mgr_module_path = /usr/share/ceph/mgr mgr_standby_modules = true I managed to fix the problem on another ceph 18 cluster many days of struggle but can't fix it on this cluster. here are the loaded modules : # ceph mgr module ls | grep on balancer on (always on) crash on (always on) devicehealth on (always on) orchestrator on (always on) pg_autoscaler on (always on) progress on (always on) rbd_support on (always on) status on (always on) telemetry on (always on) volumes on (always on) cephadm on prometheus on I'm running ceph 18.2.8 on debian 12. the aim of making cephadm work is to switch from legacy to orch / cephadm and upgrade to 20. should I consider upgrading my legacy cluster to tentacle and after that switching to cephadm ? Thanks for your help... Regards Cédric

1 2