Enheten -.mount är maskerad: OpenVPN-klienten startar inte

Din tjänst misslyckas innan OpenVPN ens körs, och felet talar om en monteringsenhet som du aldrig har konfigurerat. Det är tecknet: systemd avvisar hela transaktionen eftersom rotmonteringsenheten är maskerad, och din VPN-profil har inte lästs ännu. Den vanliga orsaken är en kvarglömd fil i runtime-katalogen för enheter, inte en trasig fstab och inte ett saknat certifikat. Följ filen först, för det är den billigaste förklaringen att utesluta.

Felet nämner rotmonteringen, inte din profil

systemd genererar rotmonteringsenheten själv från kernelnns monteringsinformation och kallar enheten -.mount eftersom ett bindestreck står för rotvägen. Den enheten finns normalt bara i minnet och har ingen fil bakom sig. När felet säger att den är maskerad har någon lagt en enhetsfil där systemd kommer att läsa in den och pekat filen mot /dev/null. Maskeringen är ett verkligt tillstånd, inte ett skrivfel i meddelandet.

Instansenheten misslyckas eftersom dess jobbgraf når rotmonteringen genom ordning och genom sina egna monteringskrav. Transaktionen avvisas innan OpenVPN-binären körs, så ingenting i klientens konfiguration kan vara orsaken. Det är därför byte av profiler, certifikat eller inloggningsuppgifter inte har någon effekt på just detta fel.

Titta i runtime-katalogen innan du felsöker OpenVPN

Leta efter en fil med exakt det namnet i runtime-katalogen för enheter och fråga sedan systemd vad den anser att enheten är. Båda svaren är snabba, och tillsammans skiljer de en kvarglömd fil från ett verkligt monteringsproblem.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

En normal maskin har ingen sådan fil, och den maskerade listan innehåller inte rotmonteringen. Om det första kommandot skriver ut en symbolisk länk till /dev/null är diagnosen klar. Samma katalog kan innehålla en tmp.mount-maskering skapad av samma verktyg, och det ger samma typ av fel under ett annat namn. Titta på hela katalogen och inte bara namnet i felet.

ls -la /run/systemd/system/*.mount

Om katalogen är ren och enheten fortfarande är maskerad ligger maskeringen någon annanstans i sökvägen, och systemctl cat -.mount visar vilken fil som läses in.

Radera filen, läs in på nytt och starta igen

Det räcker att ta bort runtime-filen och läsa in hanteraren på nytt, och det rör ingenting som kom från ett paket. Läs in på nytt före start, eftersom systemd behåller den inlästa enhetens tillstånd tills den läser katalogen igen.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

Läs sedan tjänstens egen journal i stället för att anta att åtgärden fungerade. En ren start bevisar bara att systemd accepterade enheten; klienten kan fortfarande dö på en saknad profil, en onåbar peer eller ett certifikat som inte validerar. Det är vanliga OpenVPN-problem som var gömda bakom den maskerade enheten. Journalen registrerar vilken profil som lästes in och om tunneln faktiskt upprättades. Om enheten startar och tunneln inte gör det har du flyttat dig till ett annat problem, och det är framsteg.

journalctl -u [email protected] -b --no-pager

Eftersom /run är ett tillfälligt filsystem rensar en omstart också filen. Det gör en omstart till ett användbart test: om tjänsten fungerar efter en omstart och misslyckas igen efter nästa utrullning bakas filen in i avbildningen.

Förhindra att den kommer tillbaka från avbildningen

En container- eller virtuell maskin-mall som maskerar monteringsenheter under sin byggnad tar med sig den maskeringen till varje klon. Nästa sak som behöver filsystemet går sönder, och meddelandet skyller på monteringen i stället för avbildningen den kom från. Att reparera det inne i en körande instans döljer problemet till nästa instans skapas.

Sök i byggkontexten efter filnamnet och efter kommandot som skapar det, ta sedan bort maskeringen från mallen och bygg om. Om maskeringen verkligen behövs under bygget, ta bort den i samma lager som avslutar bygget, så att avbildningen som levereras startar rent. Verifiera på en färsk klon och inte på maskinen du reparerade för hand. Det är det enda testet som bevisar att avbildningen ändrades.

Symtomet att komma ihåg är diskrepansen mellan felet och det du konfigurerade. När systemd klagar över en montering medan du startar en VPN-klient, läs enhetsnamnet i meddelandet innan du läser tjänstenamnet.