- ceph-users - lists.ceph.io

Re: Has anyone been able to use NFS in tentacle or it is really broken?
by Robert Sander 12 Apr '26

12 Apr '26

Hi, On 4/10/26 17:31, Salatiel Filho via ceph-users wrote: > It is broken. > https://tracker.ceph.com/issues/74307 > https://tracker.ceph.com/issues/74191 Thanks for the links. It looks like installing rpcbind fixes the issue. Why does the orchestrator does not install rpcbind on the node where an NFS daemon instance is to be deployed? Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 220009 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin

1 0

Re: AutoFS Timeouts with CephFS
by Anthony D'Atri 11 Apr '26

11 Apr '26

I’ve seen, of all things, an IDE periodically scanning homedirs. If that happens every five minutes .. > On Apr 10, 2026, at 3:16 PM, Paul Mezzanini via ceph-users <ceph-users(a)ceph.io> wrote: > > Is there something in cron (or some other system monitoring) that tickles mounted drives on a 5 minute interval? We leverage autofs heavily here and I've never seen that except when netdata decided it wanted to monitor EVERY MOUNT to make sure it wasn't out of disk space. > > -- > > Paul Mezzanini > Platform Engineer III > Research Computing > Rochester Institute of Technology > > > > > ________________________________________ > From: Greg Ballantine via ceph-users <ceph-users(a)ceph.io> > Sent: Friday, April 10, 2026 12:00 PM > To: ceph-users(a)ceph.io > Subject: [ceph-users] AutoFS Timeouts with CephFS > > Hi all, > > We are running into a strange issue with autofs and CephFS at UMBC. We are > attempting to manage CephFS volumes via autofs with an idle timeout, > however my volumes do not appear to be unmounting when idle. After some > digging, it appears when the timeout is set to five minutes the volumes > stay mounted indefinitely, but when the autofs timeout is set to 4.5 > minutes, the volumes unmount as expected. > > Our environment is: > > - > > Ceph cluster version: 18.2.7 > - > > Ceph client version: 18.2.1 kernel client > - > > OS: Red Hat 9.7 > - > > auto.master entry: "/umbc/rs /cm/shared/etc/autofs/mounts.rs > --timeout=300" > - > > mounts.rs entry: "archive -fstype=ceph,name=archive,fs=rrstor > ceph-mon.example.com:/archive" > > We have checked for open file descriptors using lsof, but the mount appears > idle, only showing automount processes as holding open file descriptors in > the mounts. Has anyone encountered similar behavior before and can comment > on what they think might be going on? > > Thank you, > Greg > > -- > Gregory Ballantine > HPC Specialist, Division of IT > University of Maryland, Baltimore County > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: AutoFS Timeouts with CephFS
by Paul Mezzanini 11 Apr '26

11 Apr '26

Is there something in cron (or some other system monitoring) that tickles mounted drives on a 5 minute interval? We leverage autofs heavily here and I've never seen that except when netdata decided it wanted to monitor EVERY MOUNT to make sure it wasn't out of disk space. -- Paul Mezzanini Platform Engineer III Research Computing Rochester Institute of Technology ________________________________________ From: Greg Ballantine via ceph-users <ceph-users(a)ceph.io> Sent: Friday, April 10, 2026 12:00 PM To: ceph-users(a)ceph.io Subject: [ceph-users] AutoFS Timeouts with CephFS Hi all, We are running into a strange issue with autofs and CephFS at UMBC. We are attempting to manage CephFS volumes via autofs with an idle timeout, however my volumes do not appear to be unmounting when idle. After some digging, it appears when the timeout is set to five minutes the volumes stay mounted indefinitely, but when the autofs timeout is set to 4.5 minutes, the volumes unmount as expected. Our environment is: - Ceph cluster version: 18.2.7 - Ceph client version: 18.2.1 kernel client - OS: Red Hat 9.7 - auto.master entry: "/umbc/rs /cm/shared/etc/autofs/mounts.rs --timeout=300" - mounts.rs entry: "archive -fstype=ceph,name=archive,fs=rrstor ceph-mon.example.com:/archive" We have checked for open file descriptors using lsof, but the mount appears idle, only showing automount processes as holding open file descriptors in the mounts. Has anyone encountered similar behavior before and can comment on what they think might be going on? Thank you, Greg -- Gregory Ballantine HPC Specialist, Division of IT University of Maryland, Baltimore County _______________________________________________ ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: AutoFS Timeouts with CephFS
by Stefan Möding 10 Apr '26

10 Apr '26

Hi! Greg Ballantine via ceph-users <ceph-users(a)ceph.io> writes: > We have checked for open file descriptors using lsof, but the mount appears > idle, only showing automount processes as holding open file descriptors in > the mounts. Has anyone encountered similar behavior before and can comment > on what they think might be going on? You might want to look for a monitoring/cron job that runs “df” or similar tools. I believe I have seen this issue with autofs even when only the filesystem size or free space is checked. -- Stefan

1 0

AutoFS Timeouts with CephFS
by Greg Ballantine 10 Apr '26

10 Apr '26

Hi all, We are running into a strange issue with autofs and CephFS at UMBC. We are attempting to manage CephFS volumes via autofs with an idle timeout, however my volumes do not appear to be unmounting when idle. After some digging, it appears when the timeout is set to five minutes the volumes stay mounted indefinitely, but when the autofs timeout is set to 4.5 minutes, the volumes unmount as expected. Our environment is: - Ceph cluster version: 18.2.7 - Ceph client version: 18.2.1 kernel client - OS: Red Hat 9.7 - auto.master entry: "/umbc/rs /cm/shared/etc/autofs/mounts.rs --timeout=300" - mounts.rs entry: "archive -fstype=ceph,name=archive,fs=rrstor ceph-mon.example.com:/archive" We have checked for open file descriptors using lsof, but the mount appears idle, only showing automount processes as holding open file descriptors in the mounts. Has anyone encountered similar behavior before and can comment on what they think might be going on? Thank you, Greg -- Gregory Ballantine HPC Specialist, Division of IT University of Maryland, Baltimore County

1 0

Re: Has anyone been able to use NFS in tentacle or it is really broken?
by Salatiel Filho 10 Apr '26

10 Apr '26

It is broken. https://tracker.ceph.com/issues/74307 https://tracker.ceph.com/issues/74191 Atenciosamente/Kind regards, Salatiel On Thu, Apr 9, 2026 at 9:47 AM Robert Sander via ceph-users <ceph-users(a)ceph.io> wrote: > > Hi, > > I just tried to deploy an NFS service on a freshly installed 20.2.1 cluster and it fails. > > ceph nfs cluster create nfs01 "label:nfs01" > > There is exactly one host with the label nfs01. > > There are some entries in the log showing errors but the last two are > > - Cannot acquire credentials for principal nfs > - Cannot register NFS V3 on TCP > > /var/lib/ceph/2ac9b090-3363-11f1-bd6a-bc2411d682b7/nfs.nfs01.0.0.rgw01.hpfeuz/etc/ganesha/ganesha.conf > contained "Protocols 3, 4;" in the NFS_CORE_PARAM section. > > After removing the 3 the container starts. > > NFSv3 was added in commit 1e69ebc6ceaf in February 2024. It was not contained in Ceph squid. > > > Apr 09 14:23:18 HOST systemd[1]: Starting ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7(a)nfs.nfs01.0.0.HOST.hpfeuz.service - Ceph nfs.nfs01.0.0.HOST.hpfeuz for 2ac9b090-3363-11f1-bd6a-bc2411d682b7... > Apr 09 14:23:18 HOST podman[31327]: 2026-04-09 14:23:18.942654365 +0200 CEST m=+0.048118777 container create c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, org.label-schema.name=CentOS Stream 9 Base Image, org.opencontainers.image.authors=Ceph Release Team <ceph-maintainers(a)ceph.io>, CEPH_REF=tentacle, OSD_FLAVOR=default, FROM_IMAGE=quay.io/centos/centos:stream9, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, ceph=True, org.opencontainers.image.documentation=https://docs.ceph.com/, org.label-schema.build-date=20260331, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, io.buildah.version=1.43.0, org.label-schema.license=GPLv2, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, org.label-schema.schema-version=1.0, org.label-schema.vendor=CentOS) > Apr 09 14:23:19 HOST podman[31327]: 2026-04-09 14:23:19.000318083 +0200 CEST m=+0.105782538 container init c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, io.buildah.version=1.43.0, org.opencontainers.image.authors=Ceph Release Team <ceph-maintainers(a)ceph.io>, ceph=True, org.label-schema.name=CentOS Stream 9 Base Image, org.label-schema.vendor=CentOS, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, org.label-schema.schema-version=1.0, org.label-schema.license=GPLv2, CEPH_REF=tentacle, OSD_FLAVOR=default, org.opencontainers.image.documentation=https://docs.ceph.com/, FROM_IMAGE=quay.io/centos/centos:stream9, org.label-schema.build-date=20260331) > Apr 09 14:23:19 HOST podman[31327]: 2026-04-09 14:23:19.004217805 +0200 CEST m=+0.109682235 container start c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, FROM_IMAGE=quay.io/centos/centos:stream9, org.opencontainers.image.authors=Ceph Release Team <ceph-maintainers(a)ceph.io>, CEPH_REF=tentacle, org.opencontainers.image.documentation=https://docs.ceph.com/, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, org.label-schema.vendor=CentOS, ceph=True, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, org.label-schema.name=CentOS Stream 9 Base Image, org.label-schema.build-date=20260331, org.label-schema.schema-version=1.0, OSD_FLAVOR=default, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, io.buildah.version=1.43.0, org.label-schema.license=GPLv2) > Apr 09 14:23:19 HOST bash[31327]: c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 > Apr 09 14:23:19 HOST podman[31327]: 2026-04-09 14:23:18.922220554 +0200 CEST m=+0.027684991 image pull fb63cba66eea5516fbd9a1ec035c265abdbc1a1a8fc2dc0b51057557e49ca28c quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337 > Apr 09 14:23:19 HOST systemd[1]: Started ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7(a)nfs.nfs01.0.0.HOST.hpfeuz.service - Ceph nfs.nfs01.0.0.HOST.hpfeuz for 2ac9b090-3363-11f1-bd6a-bc2411d682b7. > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] init_logging :LOG :NULL :LOG: Setting log level for all components to NIV_EVENT > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] main :MAIN :EVENT :ganesha.nfsd Starting: Ganesha Version 5.9 > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] nfs_set_param_from_conf :NFS STARTUP :EVENT :Configuration file successfully parsed > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] monitoring_init :NFS STARTUP :EVENT :Init monitoring at 0.0.0.0:9587 > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] fsal_init_fds_limit :MDCACHE LRU :EVENT :Setting the system-imposed limit on FDs to 1048576. > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] init_server_pkgs :NFS STARTUP :EVENT :Initializing ID Mapper. > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] init_server_pkgs :NFS STARTUP :EVENT :ID Mapper successfully initialized. > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] nfs_start_grace :STATE :EVENT :NFS Server Now IN GRACE, duration 90 > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] rados_kv_traverse :CLIENT ID :EVENT :Failed to lst kv ret=-2 > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] rados_cluster_read_clids :CLIENT ID :EVENT :Failed to traverse recovery db: -2 > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] nfs_start_grace :STATE :EVENT :grace reload client info completed from backend > Apr 09 14:23:19 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] nfs_try_lift_grace :STATE :EVENT :check grace:reclaim complete(0) clid count(0) > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] rados_cluster_end_grace :CLIENT ID :EVENT :Failed to remove rec-0000000000000001:0: -2 > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] nfs_lift_grace_locked :STATE :EVENT :NFS Server Now NOT IN GRACE > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] main :NFS STARTUP :WARN :No export entries found in configuration file !!! > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] config_errs_to_log :CONFIG :WARN :Config File (/etc/ganesha/ganesha.conf:9): Unknown parameter (allow_set_io_flusher_fail) > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] config_errs_to_log :CONFIG :WARN :Config File (/etc/ganesha/ganesha.conf:28): Unknown block (RADOS_URLS) > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] config_errs_to_log :CONFIG :WARN :Config File (/etc/ganesha/ganesha.conf:33): Unknown block (RGW) > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] lower_my_caps :NFS STARTUP :EVENT :CAP_SYS_RESOURCE was successfully removed for proper quota management in FSAL > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] lower_my_caps :NFS STARTUP :EVENT :currently set capabilities are: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_sys_chroot,cap_setfcap=ep > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] gsh_dbus_pkginit :DBUS :CRIT :dbus_bus_get failed (Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory) > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] gsh_dbus_register_path :DBUS :CRIT :dbus_connection_register_object_path called with no DBUS connection > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] gsh_dbus_register_path :DBUS :CRIT :dbus_connection_register_object_path called with no DBUS connection > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] gsh_dbus_register_path :DBUS :CRIT :dbus_connection_register_object_path called with no DBUS connection > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] nfs_Init_svc :DISP :CRIT :Cannot acquire credentials for principal nfs > Apr 09 14:23:22 HOST ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] __Register_program :DISP :MAJ :Cannot register NFS V3 on TCP > Apr 09 14:23:22 HOST podman[31583]: 2026-04-09 14:23:22.269193428 +0200 CEST m=+0.027823817 container died c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, OSD_FLAVOR=default, org.label-schema.vendor=CentOS, io.buildah.version=1.43.0, org.label-schema.name=CentOS Stream 9 Base Image, org.label-schema.schema-version=1.0, ceph=True, org.opencontainers.image.documentation=https://docs.ceph.com/, CEPH_REF=tentacle, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, org.label-schema.build-date=20260331, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, FROM_IMAGE=quay.io/centos/centos:stream9, org.label-schema.license=GPLv2, org.opencontainers.image.authors=Ceph Release Team <ceph-maintainers(a)ceph.io>) > Apr 09 14:23:22 HOST podman[31583]: 2026-04-09 14:23:22.325861901 +0200 CEST m=+0.084492274 container remove c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, ceph=True, org.label-schema.vendor=CentOS, CEPH_REF=tentacle, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, OSD_FLAVOR=default, org.opencontainers.image.documentation=https://docs.ceph.com/, org.label-schema.schema-version=1.0, org.label-schema.license=GPLv2, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, org.label-schema.build-date=20260331, io.buildah.version=1.43.0, org.opencontainers.image.authors=Ceph Release Team <ceph-maintainers(a)ceph.io>, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, org.label-schema.name=CentOS Stream 9 Base Image, FROM_IMAGE=quay.io/centos/centos:stream9) > Apr 09 14:23:22 HOST systemd[1]: ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7(a)nfs.nfs01.0.0.HOST.hpfeuz.service: Main process exited, code=exited, status=2/INVALIDARGUMENT > Apr 09 14:23:22 HOST systemd[1]: ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7(a)nfs.nfs01.0.0.HOST.hpfeuz.service: Failed with result 'exit-code'. > > Regards > -- > Robert Sander > Heinlein Consulting GmbH > Schwedter Str. 8/9b, 10119 Berlin > > http://www.heinlein-support.de > > Tel: 030 / 405051-43 > Fax: 030 / 405051-19 > > Zwangsangaben lt. §35a GmbHG: > HRB 220009 B / Amtsgericht Berlin-Charlottenburg, > Geschäftsführer: Peer Heinlein -- Sitz: Berlin > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

cephadm without containers
by Adrian Sevcenco 10 Apr '26

10 Apr '26

Hi! Is there any possibility to use cephadm without the container based tooling? (so to use bare-metal, with the packages directly installed on the machine) If not, is there something technical that prevents it to happen or just that there is a policy that container based deployment is the only best way to do it therefore cephadm will only use it this way? I ask this in the context of finding out that ceph-ansible is deprecated and that it should not be used, but i still need to use ansible for management and i think (so without factual experience) that bare metal services would be easier to manage after doing by hand deployment with cephadm Thank you! Adrian

11 20

Re: Questions about dm-cache
by Janne Johansson 10 Apr '26

10 Apr '26

> > A second cache mode is "writeback". Writeback delays writing data > > blocks from the cache back to the origin LV. This mode will > > increase performance, but the loss of a cache device can result in > > lost data. > > So, so much for that. Writethrough will not help my situation, and writeback can cause data loss. This leads to two questions: This isn't much different from OSD on one slow drive and WAL+DB on fast(er) drive. If wal+db disk dies, the OSD is for all practical purposes "dead" too. It is one of the things at least we accept when we use 4-6 WAL+DB-partitions on a single nvme for our spindrive hosts. Most of those have 12 drives so 2 or 3 nvmes are in there and yes losing an nvme would be bad, but still less bad than losing the host, which could occur at any time for some kernel crash or PSU fault, so losing an nvme for us, is like losing half a host, and our clusters need to be able to withstand losing a whole host so for us, it's a decent enough tradeoff. Regardless of how you set up "ssd" acceleration in front of slower disks, there will be a window where if the ssd breaks, bad things happen to the slow disk OSD behind it. Yes, write-back makes that window larger, but you probably won't get a zero timespan for catastrophes in any case. -- May the most significant bit of your life be positive.

2 1

Re: Questions about dm-cache
by Alexis Bauvin 10 Apr '26

10 Apr '26

> > A subsequent question is: is it transparent to the point I can setup the cache on a live OSD, or do I need to recreate it and have ceph-volume have a go *with* the cache setup, so it knows about it? > > The way I understand it is "ceph does not care about dm-cache" so I would need, at worst, to restart the OSD. > > > disclaimer: never used dm-cache in production, last experimented with it > several years ago. > > I seem to remember that the transparency of dm-cache comes with a risk: > LVM device name stays the same whether the cache device is attached or > not. Nothing keeps you from writing new data to the device with cache > device detached even if said caching device still contains some > unwritten data. > So you might lose that in-cache data using LVM volume when cache device > is not attached (e.g. after reboot, perhaps ceph grabbing the device > before cache device attach). And when re-attaching a cache device later > it might just kill the fs by replaying outdated cached data. > > I have used bcache in production with ceph. Bcache requires you to > format the block device as a bcache device, and the backing device knows > if cached data is missing and refuses to be mounted until the > corresponding cache device is attached and such cached data is > accessible. This provides better reliabilty, but with some upfront cost > and some additional parameters to set (cache mode, watermarks, ...) > > Still, this might just be outdated knowledge of the past, YMMV. Ah, this somewhat changes things. It appears your knowledge is is not outdated, as it is explicitly documented in the lvm-cache manpage (https://man7.org/linux/man-pages/man7/lvmcache.7.html) > A second cache mode is "writeback". Writeback delays writing data > blocks from the cache back to the origin LV. This mode will > increase performance, but the loss of a cache device can result in > lost data. So, so much for that. Writethrough will not help my situation, and writeback can cause data loss. This leads to two questions: Since Ceph is aware of dm-cache (inferred by the fact the docs mention it), will the OSD stop if the cache device is not present? My setup has WAL+DB on dedicated drives, and I planned to use the free space left on those drives as a cache. Since the OSD cannot work if WAL+DB absent, I'm in a situation where the cache can only be absent if the WAL+DB is absent too. That is, WAL+DB is here iff cache is here too. Is the reasoning correct? Or can there still be a race where OSD starts writing data to the volume before the kernel has caching setup? Thanks for the warning! Alexis > Matthias > > > > > > > Is it that I can just slap an lvm cache on the LVs created by ceph-volume and call it a day? > > > > Is this the canonical replacement to Ceph's native cache tiers? > > > > > > I guess it is one of the default alternatives now that tiering is off > > > the map. We do a lot of "put WAL + DB on nvme partition, data on > > > spin-disks" with something like 4 or 6 nvme partitions per OSD disk, > > > so this mostly improves database access parts and less of the bulk > > > data transfers, but we think that is ok. > > > > Yeah, HDD setups is what I tried to mimic, as I have the WAL+DB on actual write-intensive enterprise drives, but it can only do so much when the backend drive does GC pauses that last for 20 min and increase the IO latency to the 2s-20s range. I'm hoping caching can shield most workloads from it. > > > > > > Is the tuning of the cache settings somehow managed by Ceph or is it fully on the user? And, related, can the caching be declared in the orch OSD spec? > > > > > > If you stack devices in LVM, then I guess that is where any tuning > > > would have to happen, though I don't think there is a large need to > > > tune those settings a lot. The defaults should probably work fine for > > > most people. > > > > Noted. I don't expect to have to tune a lot, but given the (horrible) behavior of my drives, being able to tune flushes and invalidations is important. > > > > > > As for the context: I have a cluster with *very* bad SSDs (consumer DRAM-less BX500) and I'm trying to get it somewhat OK until the market for flash improves. As the problems are due to GC pauses from the drive caused by the sustained IO, I'm hoping that putting a cache tier (with smaller faster enterprise SSDs) in front of the drives will change the IO behavior enough for the drives to perform their GC without impacting the cluster. I already have the good smaller drives that have WAL+DB for the slow drives, but they have enough free space to cache the block. > > > > > > I don't have any idea on which method will be best in the end, but I > > > think dm-cache is stable enough for people to recommend it. > > > > That's what I gathered from poking around the internet. The fact that the ceph documentations mention it, while not an endorsement, is already meaningful for the viability of dm-cache. Thanks for the confirmation! > > > > Thank you for the reply and the pointers! > > > > > -- > > > May the most significant bit of your life be positive. > > _______________________________________________ > > ceph-users mailing list -- ceph-users(a)ceph.io > > To unsubscribe send an email to ceph-users-leave(a)ceph.io > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Re: Has anyone been able to use NFS in tentacle or it is really broken?
by Eugen Block 10 Apr '26

10 Apr '26

Hi, I tend to agree. I'm trying to set up an nfs cluster in a lab and fail with v20. I also was under the impression that NFSv3 isn't supported anymore, so I was just as surprised as you to see it in the config. In a different lab cluster on Squid the nfs daemon starts immediately (without v3). Regards, Eugen Zitat von Robert Sander via ceph-users <ceph-users(a)ceph.io>: > Hi, > > I just tried to deploy an NFS service on a freshly installed 20.2.1 > cluster and it fails. > > ceph nfs cluster create nfs01 "label:nfs01" > > There is exactly one host with the label nfs01. > > There are some entries in the log showing errors but the last two are > > - Cannot acquire credentials for principal nfs > - Cannot register NFS V3 on TCP > > /var/lib/ceph/2ac9b090-3363-11f1-bd6a-bc2411d682b7/nfs.nfs01.0.0.rgw01.hpfeuz/etc/ganesha/ganesha.conf > contained "Protocols 3, 4;" in the NFS_CORE_PARAM section. > > After removing the 3 the container starts. > > NFSv3 was added in commit 1e69ebc6ceaf in February 2024. It was not > contained in Ceph squid. > > > Apr 09 14:23:18 HOST systemd[1]: Starting > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7(a)nfs.nfs01.0.0.HOST.hpfeuz.service > - Ceph nfs.nfs01.0.0.HOST.hpfeuz for > 2ac9b090-3363-11f1-bd6a-bc2411d682b7... > Apr 09 14:23:18 HOST podman[31327]: 2026-04-09 14:23:18.942654365 > +0200 CEST m=+0.048118777 container create > c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 > (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, org.label-schema.name=CentOS Stream 9 Base Image, org.opencontainers.image.authors=Ceph Release Team <ceph-maintainers(a)ceph.io>, CEPH_REF=tentacle, OSD_FLAVOR=default, FROM_IMAGE=quay.io/centos/centos:stream9, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, ceph=True, org.opencontainers.image.documentation=https://docs.ceph.com/, org.label-schema.build-date=20260331, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, io.buildah.version=1.43.0, org.label-schema.license=GPLv2, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, org.label-schema.schema-version=1.0, > org.label-schema.vendor=CentOS) > Apr 09 14:23:19 HOST podman[31327]: 2026-04-09 14:23:19.000318083 > +0200 CEST m=+0.105782538 container init > c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 > (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, io.buildah.version=1.43.0, org.opencontainers.image.authors=Ceph Release Team <ceph-maintainers(a)ceph.io>, ceph=True, org.label-schema.name=CentOS Stream 9 Base Image, org.label-schema.vendor=CentOS, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, org.label-schema.schema-version=1.0, org.label-schema.license=GPLv2, CEPH_REF=tentacle, OSD_FLAVOR=default, org.opencontainers.image.documentation=https://docs.ceph.com/, FROM_IMAGE=quay.io/centos/centos:stream9, > org.label-schema.build-date=20260331) > Apr 09 14:23:19 HOST podman[31327]: 2026-04-09 14:23:19.004217805 > +0200 CEST m=+0.109682235 container start > c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 > (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, FROM_IMAGE=quay.io/centos/centos:stream9, org.opencontainers.image.authors=Ceph Release Team <ceph-maintainers(a)ceph.io>, CEPH_REF=tentacle, org.opencontainers.image.documentation=https://docs.ceph.com/, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, org.label-schema.vendor=CentOS, ceph=True, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, org.label-schema.name=CentOS Stream 9 Base Image, org.label-schema.build-date=20260331, org.label-schema.schema-version=1.0, OSD_FLAVOR=default, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, io.buildah.version=1.43.0, > org.label-schema.license=GPLv2) > Apr 09 14:23:19 HOST bash[31327]: > c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 > Apr 09 14:23:19 HOST podman[31327]: 2026-04-09 14:23:18.922220554 > +0200 CEST m=+0.027684991 image pull > fb63cba66eea5516fbd9a1ec035c265abdbc1a1a8fc2dc0b51057557e49ca28c > quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337 > Apr 09 14:23:19 HOST systemd[1]: Started > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7(a)nfs.nfs01.0.0.HOST.hpfeuz.service > - Ceph nfs.nfs01.0.0.HOST.hpfeuz for > 2ac9b090-3363-11f1-bd6a-bc2411d682b7. > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > init_logging :LOG :NULL :LOG: Setting log level for all components > to NIV_EVENT > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > main :MAIN :EVENT :ganesha.nfsd Starting: Ganesha Version 5.9 > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > nfs_set_param_from_conf :NFS STARTUP :EVENT :Configuration file > successfully parsed > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > monitoring_init :NFS STARTUP :EVENT :Init monitoring at 0.0.0.0:9587 > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > fsal_init_fds_limit :MDCACHE LRU :EVENT :Setting the system-imposed > limit on FDs to 1048576. > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > init_server_pkgs :NFS STARTUP :EVENT :Initializing ID Mapper. > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > init_server_pkgs :NFS STARTUP :EVENT :ID Mapper successfully > initialized. > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > nfs_start_grace :STATE :EVENT :NFS Server Now IN GRACE, duration 90 > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > rados_kv_traverse :CLIENT ID :EVENT :Failed to lst kv ret=-2 > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > rados_cluster_read_clids :CLIENT ID :EVENT :Failed to traverse > recovery db: -2 > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > nfs_start_grace :STATE :EVENT :grace reload client info completed > from backend > Apr 09 14:23:19 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:19 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > nfs_try_lift_grace :STATE :EVENT :check grace:reclaim complete(0) > clid count(0) > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > rados_cluster_end_grace :CLIENT ID :EVENT :Failed to remove > rec-0000000000000001:0: -2 > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > nfs_lift_grace_locked :STATE :EVENT :NFS Server Now NOT IN GRACE > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > main :NFS STARTUP :WARN :No export entries found in configuration > file !!! > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > config_errs_to_log :CONFIG :WARN :Config File > (/etc/ganesha/ganesha.conf:9): Unknown parameter > (allow_set_io_flusher_fail) > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > config_errs_to_log :CONFIG :WARN :Config File > (/etc/ganesha/ganesha.conf:28): Unknown block (RADOS_URLS) > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > config_errs_to_log :CONFIG :WARN :Config File > (/etc/ganesha/ganesha.conf:33): Unknown block (RGW) > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > lower_my_caps :NFS STARTUP :EVENT :CAP_SYS_RESOURCE was successfully > removed for proper quota management in FSAL > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > lower_my_caps :NFS STARTUP :EVENT :currently set capabilities are: > cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_sys_chroot,cap_setfcap=ep > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > gsh_dbus_pkginit :DBUS :CRIT :dbus_bus_get failed (Failed to connect > to socket /run/dbus/system_bus_socket: No such file or directory) > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > gsh_dbus_register_path :DBUS :CRIT > :dbus_connection_register_object_path called with no DBUS connection > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > gsh_dbus_register_path :DBUS :CRIT > :dbus_connection_register_object_path called with no DBUS connection > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > gsh_dbus_register_path :DBUS :CRIT > :dbus_connection_register_object_path called with no DBUS connection > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > nfs_Init_svc :DISP :CRIT :Cannot acquire credentials for principal nfs > Apr 09 14:23:22 HOST > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz[31339]: > 09/04/2026 12:23:22 : epoch 69d79a37 : HOST : ganesha.nfsd-2[main] > __Register_program :DISP :MAJ :Cannot register NFS V3 on TCP > Apr 09 14:23:22 HOST podman[31583]: 2026-04-09 14:23:22.269193428 > +0200 CEST m=+0.027823817 container died > c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 > (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, OSD_FLAVOR=default, org.label-schema.vendor=CentOS, io.buildah.version=1.43.0, org.label-schema.name=CentOS Stream 9 Base Image, org.label-schema.schema-version=1.0, ceph=True, org.opencontainers.image.documentation=https://docs.ceph.com/, CEPH_REF=tentacle, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, org.label-schema.build-date=20260331, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, FROM_IMAGE=quay.io/centos/centos:stream9, org.label-schema.license=GPLv2, org.opencontainers.image.authors=Ceph Release Team > <ceph-maintainers(a)ceph.io>) > Apr 09 14:23:22 HOST podman[31583]: 2026-04-09 14:23:22.325861901 > +0200 CEST m=+0.084492274 container remove > c2b0e96637297b20d6bd39bf1eb68fc70b0fb5635dc72c9b887eeb82cd2bac77 > (image=quay.io/ceph/ceph@sha256:0bae386bc859cd9a05b804d1ca16cca8853a64f90809044e2bf43095419dc337, name=ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7-nfs-nfs01-0-0-HOST-hpfeuz, ceph=True, org.label-schema.vendor=CentOS, CEPH_REF=tentacle, GANESHA_REPO_BASEURL=https://buildlogs.centos.org/centos/$releasever-stream…, OSD_FLAVOR=default, org.opencontainers.image.documentation=https://docs.ceph.com/, org.label-schema.schema-version=1.0, org.label-schema.license=GPLv2, CEPH_SHA1=6a49aff47758778a5f5951e731d437c317f72fb2, org.label-schema.build-date=20260331, io.buildah.version=1.43.0, org.opencontainers.image.authors=Ceph Release Team <ceph-maintainers(a)ceph.io>, CEPH_GIT_REPO=https://github.com/ceph/ceph.git, org.label-schema.name=CentOS Stream 9 Base Image, > FROM_IMAGE=quay.io/centos/centos:stream9) > Apr 09 14:23:22 HOST systemd[1]: > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7(a)nfs.nfs01.0.0.HOST.hpfeuz.service: > Main process exited, code=exited, status=2/INVALIDARGUMENT > Apr 09 14:23:22 HOST systemd[1]: > ceph-2ac9b090-3363-11f1-bd6a-bc2411d682b7(a)nfs.nfs01.0.0.HOST.hpfeuz.service: > Failed with result 'exit-code'. > > Regards > -- > Robert Sander > Heinlein Consulting GmbH > Schwedter Str. 8/9b, 10119 Berlin > > http://www.heinlein-support.de > > Tel: 030 / 405051-43 > Fax: 030 / 405051-19 > > Zwangsangaben lt. §35a GmbHG: > HRB 220009 B / Amtsgericht Berlin-Charlottenburg, > Geschäftsführer: Peer Heinlein -- Sitz: Berlin > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0