zdenerwowany pingwin

Brak możliwości zapisu pliku konfiguracyjnego ZNC: Error while locking the new config file, errno says: Permission denied

Od 2 miesięcy borykałem się z problemem związanym z poprawnym zamykaniem bouncera ZNC, co zapoczątkowałem poszukiwaniami, poruszeniem tematu na socialach (Mastodom, IRC), a finalnie poległszy w temacie, napisałem na Issue Trackerze ZNC. Efekt? Ciągle ten sam – każdorazowe wywołanie komend:

/znc shutdown
/znc saveconfig

Owocowało błędem:

Zrzut ekranu z komunikatem błędu "Error while locking the new config file, errno says: Permission denied" i zapisem z logu Debugowania ZNC
Error while locking the new config file, errno says: Permission denied

Wstępna diagnoza/podejrzenia

Pierwsze co nasuwa się po przeanalizowaniu błędu to po prostu błędnie nadane uprawnienia. Opcji wiele nie ma, ponieważ może być to zły CHMOD, lub prawa własności. Przejrzałem więc wszystkie katalogi, czy foldery mają co najmniej CHMOD 700, a pliki 600. Wszystko grało… błąd występował nadal.

Ustawiłem więc ponownie prawa własności i uprawnienia na pliki/katalogi:

chown -R inzaghi89:inzaghi89 .znc
find .znc/ -type d -exec 700 {} \;
find .znc/ -type f -exec 600 {} \;

Zgadnijcie? No błąd k… dalej występował ten sam. I tak mijały dni, tygodnie. Do dziś, gdy uznałem – nie ma wała, muszę znaleźć co powoduje ten problem, bo to na pewno nie kwestia uprawnień i pliku konfiguracyjnego. Wszakże konfigurację mam od dekady tę samą, niezmienną.

Szukanie w nieoczywistym

Gdy pisałem zgłoszenie na issue trackerze ZNC, zapaliła mi się już wtedy lampka, że mogło mieć to związek z aktualizacją Ubuntu, bo już wtedy obserwowałem problemy przy próbie wyłączenia ZNC. Ale nie bardzo wiedziałem gdzie szukać i za co się zabrać, a poza tym nie bardzo też miałem chęć, bo i tak nie planowałem wprowadzać żadnych modyfikacji w konfiguracji. Działa? Nie ruszaj. Złota zasada IT.

Bardzo jednak chciałem to rozwiązać.

Niezwykle pomocny okazał się tutaj dmesg, który nakierował, gdzie może tkwić problem. I, jak się później okazało wcale nie był winny ZNC, a rzeczywiście któraś aktualizacja Ubuntu, a właściwie to apparmor.

Szybkie:

dmesg | tail

Które pozwoliło zobaczyć coś nieoczywistego:

[598665.623862] audit: type=1400 audit(1757179928.787:230): apparmor="DENIED" operation="file_lock" class="file" profile="znc" name="/home/inzaghi89/.znc/configs/znc.conf~" pid=304537 comm="znc" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000

Dwa miesiące szukania, by zobaczyć, że apparmor nie ma maski „k” w konfiguracji ZNC.

Szybki fix, szybszy niż znalezienie problemu

nano /etc/apparmor.d/znc

Szybkie Ctrl+W i szukanie frazy .conf, by zauważyć, że rzeczywiście plik tymczasowy nie ma odpowiedniej maski ustawionej:

  owner @{HOME}/.znc/configs/znc.conf~ rw, #o tu, linia 26, wystarczy dodać: k

          [ lin. 26/43 (60%), kol. 33/43 ( 76%), zn.  637/1170 (54%) ]

Szybkie dopisanie „k”, by linia 26 wyglądała następująco

  owner @{HOME}/.znc/configs/znc.conf~ rwk,

Ctrl+O, ponowne zaczytanie konfiguracji apparmor dla ZNC

sudo apparmor_parser -r /etc/apparmor.d/znc

I od tej pory wszystko działa, jak powinno. Smacznego! :)


Komentarze

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *