🔍 Das Problem
Neulich hatte ich ein kurioses Problem beim Mounten eines CephFS-Volumes.
Eigentlich nichts Besonderes – bis plötzlich beim Einbinden folgende Fehlermeldungen im Kernel-Log auftauchten:
libceph: auth protocol 'cephx' mauth authentication failed: -13
ceph: No mds server is up or the cluster is laggy
mount error: no mds server is up or the cluster is laggy
Klingt nach einem kaputten MDS oder einem überlasteten Cluster, oder?
Das dachte ich auch – bis sich herausstellte, dass der Fehler ganz woanders lag.
⚙️ Symptome & Fehlersuche
Beim manuellen Mount-Versuch mit:
mount -t ceph 10.0.0.101,10.0.0.103,10.0.0.105,10.0.0.108,10.0.0.111:/kubernetes/K00XXXXXX /mnt \
-o name=client.K00XXXXXX,secretfile=/etc/ceph/client.K00XXXXXX.secret
oder über /etc/fstab bekam ich immer denselben Fehler.
In dmesg und strace tauchte zusätzlich auf:
mount(..., "ceph", ..., "name=client.K00XXXXXX,...") = -1 EHOSTUNREACH
Der Ceph-Cluster selbst war aber völlig gesund:
ceph -s
zeigte ein sauberes
cluster: HEALTH_OK
Also kein Netzwerkproblem, kein kaputtes MDS, kein Latenzthema.
Aber der Mount verweigerte weiterhin den Dienst.
🧩 Die eigentliche Ursache
Nach einer Weile Debugging kam der entscheidende Aha-Moment:
Das Problem lag am Parameter
namein der fstab!
Der Ceph-Mount-Helper setzt nämlich automatisch das Präfix client. vor den Namen.
Wenn man also in der /etc/fstab folgendes einträgt:
name=client.K00XXXXXX
dann interpretiert Ceph das intern als:
client.client.K00XXXXXX
Und genau dieser Benutzer existiert natürlich nicht.
Das Ergebnis: auth-Fehler (-13) und die irreführende Fehlermeldung „No MDS server is up or the cluster is laggy“.
✅ Die Lösung
In der /etc/fstab darf also kein client.-Präfix enthalten sein.
Korrekt sieht es so aus:
10.0.0.101,10.0.0.103,10.0.0.105,10.0.0.108,10.0.0.111:/kubernetes/K00XXXXXX /mnt ceph name=K00XXXXXX,secretfile=/etc/ceph/client.K00XXXXXX.secret,_netdev,noatime 0 2
Danach reicht ein einfaches:
mount -av
und das Volume wird sofort erfolgreich eingebunden. 🎉
🧹 Optional: alte Keys löschen
Wenn du zuvor mehrfach falsche Mounts versucht hast, kann es helfen, alte Keys zu löschen:
keyctl show
keyctl clear @s
Dadurch wird der Kernel-Keyring geleert.
💡 Fazit
Wenn CephFS beim Mounten mit „No MDS server is up or the cluster is laggy“ scheitert,
liegt das nicht immer am Cluster selbst – manchmal ist es nur ein kleiner Parameterfehler in der fstab.
Diese Falle ist besonders tückisch, weil der Fehlertext völlig in die falsche Richtung zeigt.
Aber: wieder was gelernt – und vielleicht erspart euch dieser Beitrag ein paar Stunden Fehlersuche. 😉
🧠 TL;DR
- Ceph mount schlägt fehl mit
auth protocol 'cephx' ... failed: -13 - Kein Problem mit MDS oder Netzwerk
- Schuld war
name=client.<user>in/etc/fstab - Lösung:
name=<user>ohne Prefixclient.
🔗 Nützliche Befehle zum Debuggen
# Clusterstatus prüfen
ceph -s
ceph fs status
ceph mds stat
# Mount testen (Userspace-Client)
ceph-fuse -m 10.0.0.101,10.0.0.103,10.0.0.105,10.0.0.108,10.0.0.111 /mnt \
-n client.K00XXXXXX --keyring /etc/ceph/ceph.client.K00XXXXXX.keyring -f
📚 Tags
#ceph #linux #storage #fstab #mount #troubleshooting #netz-guru