When referencing ceph.conf, mount.ceph does a much better job of figuring out using messenger v1 or v2. When specifying mon servers via mount.ceph, I was able to repeat the hang using ms_mode=legacy, and the mounts succeeded if I included ms_mode=crc,secure, prefer-crc, etc. So, I probably have something not right in trying to re-enable messenger v1 on the cluster, but this is still mildly odd behavior. On Mon, Sep 15, 2025 at 4:50 PM John Jasen <jjasen@gmail.com> wrote:

So, when I try to get a container to mount via cephfs, it uses these options:

"-t ceph cephfs@60eb7a9e-8cc6-11f0-a7d0-e43d1a153e91.k8cephfs=/volumes/k8s/csi-vol-c76f1825-df8e-477e-981a-bf5fccb66fe3/fbed6ce0-4446-449c-9a14-8c7b297499a2 /var/lib/kubelet/plugins/ kubernetes.io/csi/cephfs.csi.ceph.com/153624a7bdfffe5dfdec7dfd5c866889b7a54fb79934813e119401b3f1d36933/globalmount -o mon_addr=my.ip.addr.1:3300/my.ip.addr.5:3300/my.ip.addr.6:3300/my.ip.addr.7:3300/my.ipaddr.11:3300,secretfile=/tmp/csi/keys/keyfile-4057439945,_netdev"

And it fails:

stderr: mount error: no mds (Metadata Server) is up. The cluster might be laggy, or you may not be authorized

When I feed these options into mount.ceph, it fails, with the same errors.

When I feed each of my.ip.addr into mount.ceph as mon_addr, I get similar failures.

When I remove mon_addr options totally from the mount.ceph command, forcing it to work through /etc/ceph/ceph.conf for finding monitors -- it succeeds.

ceph.conf is a minimal one built from ceph config generate-minimal-conf, which reads:

"# minimal ceph.conf for 60eb7a9e-8cc6-11f0-a7d0-e43d1a153e91 [global] fsid = 60eb7a9e-8cc6-11f0-a7d0-e43d1a153e91 mon_host = [v2:my.ip.addr.11:3300/0,v1:my.ip.addr.11:6789/0] [v2:my.ip.addr.1:3300/0,v1:my.ip.addr.1:6789/0] v2:my.ip.addr.5:3300/0 [v2:my.ip.addr.6:3300/0,v1:my.ip.addr.6:6789/0] [v2:my.ip.addr.7:3300/0,v1:172.17. 10.7:6789/0]"

Any idea what's going on?