Unuo -.mount estas maskita: OpenVPN-kliento ne ekfunkcios

Via servo malsukcesas antaŭ ol OpenVPN eĉ ruliĝas, kaj la eraro parolas pri muntunuo, kiun vi neniam agordis. Tio estas la signo: systemd rifuzas la tutan transakcion ĉar la radika muntunuo estas maskita, kaj via VPN-profilo ankoraŭ ne estas legita. La kutima kaŭzo estas restinta dosiero en la rultempa unuodosierujo, ne rompita fstab kaj ne mankanta atestilo. Sekvu unue la dosieron, ĉar tio estas la plej malmultekosta klarigo forigi.

La eraro nomas la radikan muntaĵon, ne vian profilon

systemd mem kreas la radikan muntunuon el la muntinformoj de la kerno, kaj nomas la unuon -.mount ĉar streko reprezentas la radikan vojon. Tiu unuo kutime ekzistas nur en memoro kaj havas neniun dosieron malantaŭ si. Kiam la eraro diras, ke ĝi estas maskita, iu metis unuodosieron tie, kie systemd ŝargos ĝin, kaj direktis tiun dosieron al /dev/null. La masko estas reala stato, ne tajperaro en la mesaĝo.

La instanca unuo malsukcesas ĉar ĝia taskografio atingas la radikan muntaĵon per ordigo kaj per siaj propraj muntpostuloj. La transakcio estas rifuzata antaŭ ol la OpenVPN-binara dosiero estas ruligita, do nenio en la klienta agordo povas esti la kaŭzo. Tial ŝanĝi profilojn, atestilojn aŭ akreditaĵojn havas neniun efikon al ĉi tiu konkreta malsukceso.

Rigardu la rultempan dosierujon antaŭ ol sencimigi OpenVPN

Serĉu dosieron kun ĝuste tiu nomo en la rultempa unuodosierujo, poste demandu systemd, kion ĝi opinias la unuo. Ambaŭ respondoj estas rapidaj, kaj kune ili apartigas restintan dosieron de vera muntproblemo.

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

Normala maŝino havas neniun tian dosieron, kaj la listo de maskitaj ne enhavas la radikan muntaĵon. Se la unua komando presas simbolan ligilon al /dev/null, la diagnozo estas fiksita. La sama dosierujo povas enhavi tmp.mount-maskon kreitan de la samaj iloj, kaj tio produktas la saman klason de malsukceso sub alia nomo. Rigardu la tutan dosierujon kaj ne nur la nomon en la eraro.

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

Se la dosierujo estas pura kaj la unuo ankoraŭ estas maskita, la masko troviĝas aliloke en la serĉvojo, kaj systemctl cat -.mount montros, kiu dosiero estas ŝargata.

Forigu la dosieron, reŝargu kaj restartu

Sufiĉas forigi la rultempan dosieron kaj reŝargi la administrilon, kaj tio tuŝas nenion, kio venis el pako. Reŝargu antaŭ ol starti, ĉar systemd konservas la ŝargitan staton de la unuo ĝis ĝi relagos la dosierujon.

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

Poste legu la taglibron de la servo mem anstataŭ supozi, ke la ripeto funkciis. Pura starto pruvas nur, ke systemd akceptis la unuon; la kliento ankoraŭ povas morti pro mankanta profilo, neatingebla kunulo aŭ atestilo, kiu ne validiĝas. Tiuj estas ordinaraj OpenVPN-problemoj, kiuj kaŝiĝis malantaŭ la maskita unuo. La taglibro registras, kiu profilo estis ŝargita kaj ĉu la tunelo vere establiĝis. Se la unuo startas kaj la tunelo ne, vi transiris al alia problemo, kaj tio estas progreso.

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

Ĉar /run estas portempa dosiersistemo, restarto ankaŭ forigas la dosieron. Tio igas restartadon utila testo: se la servo funkcias post restarto kaj denove malsukcesas post la sekva deplojo, la dosiero estas bakata en la bildon.

Malebligu, ke ĝi revenu el la bildo

Kontenera aŭ virtualmaŝina ŝablono, kiu maskas muntunuojn dum sia konstruo, portos tiun maskon al ĉiu klono. La sekva afero, kiu bezonas la dosiersistemon, rompiĝas, kaj la mesaĝo kulpigas la muntaĵon anstataŭ la bildon, el kiu ĝi venis. Ripari ene de unu funkcianta instanco kaŝas la problemon ĝis la sekva instanco estas kreata.

Serĉu en la konstrua kunteksto la dosiernomon kaj la komandon, kiu kreas ĝin, poste forigu la maskon el la ŝablono kaj rekonstruu. Se la masko vere necesas dum la konstruo, forigu ĝin en la sama tavolo, kiu finas la konstruon, por ke la sendata bildo startu pure. Kontrolu sur freŝa klono kaj ne sur la maŝino, kiun vi riparis permane. Tio estas la sola testo, kiu pruvas, ke la bildo ŝanĝiĝis.

La simptomo memorinda estas la miskongruo inter la eraro kaj la afero, kiun vi agordis. Kiam systemd plendas pri muntaĵo dum vi startas VPN-klienton, legu unue la unuan nomon en la mesaĝo kaj poste la servan nomon.