Kategória: Synology

Nincsenek hozzászólások

Emby és Jellyfin párhuzamos futtatása Synology DS220+ NAS-on – csomagként, Container nélkül

  Szerző: ,

Az otthoni médiaszerver-építésnél gyakori kérdés, hogy lehet-e egyszerre több szervert futtatni ugyanazon NAS-on – például Emby-t és Jellyfin-t párhuzamosan.
Ebben a bejegyzésben azt mutatom be, hogyan néz ki a gyakorlatban a két „csomagos” (nem Dockeres) telepítés és használat Synology DS220+ NAS-on, DSM 7 alatt, és miért ütközünk bele elég hamar a portok és a csomagrendszer korlátaiba.

Kiindulási környezet

  • NAS: Synology DS220+
  • DSM: 7.x
  • Emby Server: Synology Csomagkezelési Központból telepített, nem Dockeres csomag
  • Jellyfin: szintén csomagként szeretnénk telepíteni (teszt célból, Container nélkül)
  • Cél: Emby és Jellyfin párhuzamos futtatása ugyanazon NAS-on, anélkül, hogy Docker/Container Managerre támaszkodnánk.

Fontos kiindulási pont: mind az Emby, mind a Jellyfin történetileg ugyanazt a portpárt használja alapértelmezésként:

  • HTTP: 8096
  • HTTPS: 8920

Már ebből sejthető, hogy ugyanazon hoston a párhuzamos futtatás portütközéshez vezet, ha nem választunk szét portokat.

Emby konfiguráció – system.xml és portok

Synology DSM 7 alatt az Emby Server adatkönyvtára csomagos telepítésnél a következő helyen található:

bash/volume1/@appdata/EmbyServer

Itt a config könyvtárban találjuk a központi konfigurációs fájlt:

bash/volume1/@appdata/EmbyServer/config/system.xml

SSH-n rootként bejelentkezve:

bashcd /volume1/@appdata/EmbyServer/config
ls -l

A system.xml ebben a környezetben többek között a portbeállításokat is tartalmazza. Egy tipikus részlet így néz ki:

xml<?xml version="1.0"?>
<ServerConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <EnableUPnP>true</EnableUPnP>
  <PublicPort>8096</PublicPort>
  <PublicHttpsPort>8920</PublicHttpsPort>
  <HttpServerPortNumber>8096</HttpServerPortNumber>
  <HttpsPortNumber>8920</HttpsPortNumber>
  <EnableHttps>false</EnableHttps>
  <!-- ... további beállítások ... -->
</ServerConfiguration>

Ha az Emby portját át akarjuk állítani (például 8099-re), akkor nano-val (vi mellőzésével) egyszerűen szerkeszthetjük:

bashnano /volume1/@appdata/EmbyServer/config/system.xml

És módosítjuk:

xml  <PublicPort>8099</PublicPort>
  <PublicHttpsPort>8922</PublicHttpsPort>
  <HttpServerPortNumber>8099</HttpServerPortNumber>
  <HttpsPortNumber>8922</HttpsPortNumber>

Mentés (Ctrl+O, Enter) és kilépés (Ctrl+X) után az Emby csomagot újra kell indítani DSM-ben:

  • Csomagkezelési központ → Emby Server → Leállítás → Indítás

Vagy SSH-n:

bashsynoservice --restart pkgctl-EmbyServer

Ezután az Emby az új porton érhető el:

texthttp://NAS_IP:8099

Látszólag ezzel megoldottuk, hogy Emby ne a klasszikus 8096-os porton fusson. A probléma viszont DSM-nél mélyebben gyökerezik.

Miért ütközik mégis Jellyfin és Emby csomagként?

A Jellyfin – történetileg Emby fork – alapértelmezésként ugyanazt a portpárt használja (8096/8920).
Ha Jellyfin-t is Synology csomagként próbáljuk telepíteni DSM 7 alatt, a telepítő nem csak azt nézi, hogy a port ténylegesen foglalt-e futó processz által, hanem azt is, hogy a csomagrendszer metadata szerint a port adott csomaghoz tartozik-e.

Ez gyakorlatban azt jelenti:

  • Ha Emby csomag telepítve van, a Synology Package Center úgy tekinti, hogy 8096/8920 „Emby portok”, függetlenül attól, hogy a system.xml-ben később átállítottuk 8099/8922-re.
  • Jellyfin csomag telepítője a saját default portjai alapján ütközést lát, és blokkolja a telepítést.
  • Fordítva ugyanígy: ha Jellyfin van fenn, Emby telepítése ütközhet, még akkor is, ha Jellyfinnél már átírtuk a portokat.

A fórumokban több beszámoló van arról, hogy:

  • Emby és Jellyfin csomag egyszerre a Synology-n portütközésbe fut,
  • a telepítők nem kezelik jól azt a helyzetet, amikor a default portot utólag átírják,
  • gyakran az egyik csomag uninstallja sem takarítja ki teljesen a port-hozzárendelést, így „szellem” konfliktusok maradnak.

Kipróbált megoldási irányok (laborjelleggel)

Tesztként végig lehet próbálni a következő sorrendeket:

1. Emby → port átállítása → Jellyfin telepítés

  • Emby csomag telepítése Csomagkezelési központból
  • Emby port átállítása a system.xml-ben 8099/8922-re
  • Jellyfin csomag telepítési kísérlete

Gyakorlati tapasztalat: a Jellyfin telepítő továbbra is portütközést jelez (8096/8920), hiába fut Emby másik porton. A csomagrendszer metadata szerint a portokat továbbra is Emby birtokolja.

2. Emby uninstall → Jellyfin install → Jellyfin port átállítás → Emby reinstall

Ez egy sokat ajánlott workaround:

  1. Emby csomag eltávolítása
  2. NAS reboot
  3. Jellyfin csomag telepítése (most már nincs Emby)
  4. Jellyfin adminban a portok átállítása (pl. HTTP 8096 → 8097)
  5. Jellyfin csomag újraindítása
  6. Emby csomag újbóli telepítése

Gyakorlati tapasztalat: bizonyos DSM + csomag verzióknál még így is előfordul, hogy az Emby telepítő portütközésre hivatkozik, annak ellenére, hogy Jellyfin már más porton fut.
Ennek oka, hogy a Jellyfin csomag saját default portdeclarációja továbbra is 8096/8920, és a csomagrendszer metadata alapján mindkét csomag „azonos portkészletre” pályázik.

Portok és folyamatok ellenőrzése parancssorból

Adja magát, hogy SSH-n rootként megnézzük, ki foglalja ténylegesen a portokat:

bashnetstat -tulpn | grep 8096
netstat -tulpn | grep 8920

Vagy modern rendszer esetén:

bashss -tulpn | grep 8096
ss -tulpn | grep 8920

Tesztkörnyezetben gyakran az derül ki, hogy nincs aktív processz a kérdéses portokon, mégis a csomagtelepítő ütközést jelez.
Ez megerősíti, hogy a konfliktus nem csak runtime portfoglalásról szól, hanem a DSM csomagrendszerben tárolt port-hozzárendelésről.

DSM logok és csomag-metadata – hol érdemes keresni?

Ha mélyebben szeretnénk megvizsgálni, miért áll le egy telepítő:

  • DSM Log Center:
    • Csomagtelepítési hibaüzenetek, portkonfliktusra utaló bejegyzések.
  • Csomag metadata / konfiguráció:
    • /var/packages/EmbyServer/ és /var/packages/Jellyfin/ alatt találhatók a csomaghoz tartozó fájlok, service definíciók, esetleges portbejegyzések.
    • Egyes környezetekben supervisord/service configfájlok (*.sc vagy ini) hivatkoznak explicit 8096/8920-ra.

Ezeknek az elemzése már reverse engineering-jellegű: kideríthető, hol deklarálja a csomag a portjait, és elvileg kézzel átírható lenne – de ez már nem támogatott, könnyen törékeny megoldás, és DSM frissítésnél, csomag update-nél visszajöhet a konfliktus.

Következtetés: megvalósítható-e a párhuzamos csomagos használat?

A teszt gyakorlati eredménye:

  • Elméletben: ha az egyik rendszer default portját install után átállítjuk, és a másikat csak ezután rakjuk fel, elvileg futtatható lenne párhuzamosan Emby és Jellyfin.
  • Gyakorlatban DSM 7-en:
    • A csomagtelepítők és a Synology Package Center portlogikája miatt legalább az egyik telepítésnél portütközésbe ütközünk.
    • A rendszer a default portokra épít, és nem veszi figyelembe a később átírt configot (system.xml, Jellyfin networking UI).
    • Több uninstall/reinstall és portellenőrzés után is előfordul, hogy vagy Jellyfin, vagy Emby telepítése megakad.

Ezért a konklúzió szakmai szempontból:

  • Tiszta, támogatott megoldás DSM 7-en:
    • Emby csomagként, Jellyfin konténerben (Docker/Container Manager), vagy fordítva.
    • Vagy csak az egyik médiaszerver, a másik helyett.
  • Csomagos Emby + csomagos Jellyfin egyidejű futtatása ugyanazon NAS-on, Container nélkül:
    • Elvi szinten megpróbálható,
    • de a gyakorlatban nem tekinthető stabil, támogatott konfigurációnak, mert a DSM csomagrendszer default portokra támaszkodik és konfliktusba kerül a két csomag telepítésekor.

Ha valaki kísérletezni akar vele, érdemes dokumentáltan, mentésekkel, tesztkörnyezetben próbálkozni, és elfogadni, hogy egy DSM frissítés vagy csomag update után bármikor visszatérhetnek a port-problémák.

Mit érdemes erről hazavinni rendszergazda szemmel?

  • Synology DSM 7 alatt a csomagrendszer nem arra lett kitalálva, hogy több, azonos default portot használó médiaszervert csomagként párhuzamosan fusson.
  • A hivatalos Jellyfin útmutatók sem véletlenül tolják Container Manager irányába a DSM telepítést: ott a portkiosztás teljesen a rendszergazda kezében van, nem a csomagrendszerben bedrótozott defaultokon múlik.
  • Ha a cél megbízható, hosszú távú használat és egyszerű frissíthetőség, akkor a vegyes modell (egyik csomag, másik konténer) jelenleg pragmatikusabb, mint a tisztán csomagos „kettős” setup.

Gyakori kérdések (FAQ) – Emby + Jellyfin Synology DS220+ NAS-on

Az alábbiakban összegyűjtöttem néhány gyakori kérdést és választ az Emby és Jellyfin párhuzamos, csomagos használatával kapcsolatban Synology DS220+ NAS-on, DSM 7 alatt.

1. Miért nem elég az Emby portját átírni a system.xml-ben?

A system.xml az Emby saját futási konfigurációja, amit maga az Emby szerver olvas be, és ennek alapján indul el az adott portokon.
A Synology DSM Csomagkezelési Központ viszont külön metaadatban tárolja, hogy egy csomag milyen portokat használ, és telepítéskor/ellenőrzéskor ezeket a default portokat veszi figyelembe – nem feltétlenül a később módosított configfájlt.
Ezért hiába fut Emby már 8099-es porton, a csomagrendszer szemében 8096 továbbra is „Emby port” maradhat, ami ütközhet Jellyfin default beállításaival.

2. Miért ütközik Jellyfin és Emby portszinten, ha mindkettő csomagként van telepítve?

Mindkét médiaszerver történetileg ugyanazt a portpárt használja: HTTP 8096, HTTPS 8920.
Synology DSM 7 alatt, ha Jellyfin csomag telepítőt futtatunk, az ugyanazokat a default portokat deklarálja, mint az Emby csomag.
A csomagtelepítők és a DSM portellenőrzése emiatt azt látja, hogy két külön csomag ugyanarra a portkészletre pályázik – ez portütközéshez és telepítési hibához vezet, még akkor is, ha utólag átírjuk Emby vagy Jellyfin portjait a saját konfigurációjukban.

3. Ha Jellyfin portját átállítom admin felületen, miért akad el később az Emby telepítése?

Jellyfin admin felületén (Dashboard → Networking) módosítható a „Local HTTP port” és „Local HTTPS port”, és ez a futó Jellyfin szerver viselkedését befolyásolja.
A Synology csomagrendszer azonban a csomaghoz tartozó default portdeklarációt továbbra is 8096/8920-ként ismerheti, így Emby telepítője azt látja, hogy ezek a portok „Jellyfinhez” tartoznak – ezért blokkolhatja az Emby csomag telepítését portütközésre hivatkozva, függetlenül a runtime beállításoktól.
Ez tipikusan akkor jön elő, amikor Jellyfin már csomagként fenn van, és utólag próbálunk Emby-t feltenni.

4. Létezik stabil, támogatott mód arra, hogy Emby és Jellyfin párhuzamosan fusson ugyanazon Synology NAS-on?

Igen, de a gyakorlat azt mutatja, hogy DSM 7 alatt nem a „két csomag” modell az, ami stabilan működik.
A leginkább támogatott és rugalmas megoldás jelenleg:

  • az egyik médiaszerver (például Emby) csomagként fut,
  • a másik (például Jellyfin) Docker/Container Managerben, konténerként.

Így külön host portmappinget tudsz beállítani (pl. Jellyfin 8097, Emby 8099), és a csomagrendszer portlogikája nem ütközik a konténeres szolgáltatással.
Ez különösen akkor fontos, ha egy NAS-on több médiaszervert is párhuzamosan szeretnél használni (Emby, Jellyfin, Plex stb.).

5. Akkor egyáltalán nem lehet csomagos Emby + csomagos Jellyfin párost használni DSM 7-en?

Elméletben kifaragható egy olyan setup, ahol:

  • az egyik rendszert ideiglenesen eltávolítod,
  • a másikat felteszed, átállítod a portot,
  • majd visszarakod az elsőt,

de a gyakorlati tapasztalat az, hogy ez könnyen port- és csomagtelepítési hibákhoz vezet, és frissítéseknél/upgrade-eknél ismét előjönnek a problémák.
Szakmai szemmel ez a konfiguráció nem tekinthető stabil, hosszú távon karbantartható, „production-ready” megoldásnak, inkább labor-teszt jellegű kísérlet.

6. Miért ajánlja Jellyfin hivatalosan a Docker/Container Manageres telepítést Synology DSM 7-hez?

A Jellyfin DSM 7-es telepítési útmutatói egyértelműen a konténeres telepítést preferálják, mert:

  • a portkiosztást teljesen te döntöd el (host port ⇔ konténer port),
  • független a DSM csomagrendszer default portjaitól,
  • frissítéskor, rollbackkor és több médiaszerver párhuzamos futtatásakor jóval kevesebb csomagszintű ütközés van.

Konténeres Jellyfin használatával elkerülhető az a helyzet, hogy a Jellyfin és Emby csomag ugyanazokat a portokat akarja lefoglalni, és telepítéskor egymást blokkolják.

7. Összefoglalva: mit érdemes választani, ha stabil rendszer kell?

  • Ha csak egy médiaszerver kell:
    • válaszd azt (Emby, Jellyfin, Plex), amelyik neked funkcionalitásban, kliensekben és UI-ban a leginkább megfelel, és futtasd csomagként vagy konténerben, de ne keverd feleslegesen több megoldást egy NAS-on.
  • Ha kettőt szeretnél párhuzamosan:
    • a gyakorlatban jelenleg az a stabil megoldás, ha az egyik csomagként, a másik konténerben fut, külön portokon.
    • Így DSM csomagrendszer és konténeres világ szépen együtt tud élni, portütközés és telepítési konfliktus nélkül.

🙂

UPDATE!!! Sikerült feltenni 🙂

Haladó rész: Emby metaadat-hekkelés rövid időre, Jellyfin csomag telepítéséhez

Az alap bejegyzésben arra jutottunk, hogy DSM 7 alatt a csomagos Emby és csomagos Jellyfin párhuzamos használata portszinten problémás, mert mindkettő 8096/8920 portpárra épít, és a csomagtelepítők, illetve a DSM Csomagkezelési Központ ezeket ütközésként kezeli.
A gyakorlatban viszont egy rövid idejű, célzott metaadat-hekkeléssel elértük, hogy Jellyfin csomag fel tudjon települni Emby mellé – Container használata nélkül.

Ez a szekció labor jellegű, haladó rendszergazdai lépéseket tartalmaz, és nem tekinthető hivatalosan támogatott módszernek. Production NAS-on csak tudatosan, mentésekkel és dokumentálással érdemes alkalmazni.

Cél

  • Emby már csomagként telepítve DSM 7 alatt.
  • Emby runtime portjai átállítva 8099/8922-re (system.xml alapján).
  • Jellyfin csomagot szeretnénk telepíteni Csomagkezelési Központból úgy, hogy ne lásson portütközést 8096/8920 miatt.

Ehhez elérjük, hogy DSM minden szinten azt „higgye”, Emby 8099/8922 portokat használ, ne a klasszikus 8096/8920-at – legalább addig, amíg a Jellyfin telepítés átmegy.

1. Emby runtime portjainak átállítása (system.xml)

Ez az „alap” lépés, amit már korábban részletesen leírtunk:

bashnano /volume1/@appdata/EmbyServer/config/system.xml

Portok módosítása:

xml  <PublicPort>8099</PublicPort>
  <PublicHttpsPort>8922</PublicHttpsPort>
  <HttpServerPortNumber>8099</HttpServerPortNumber>
  <HttpsPortNumber>8922</HttpsPortNumber>

Mentés után Emby restart:

bashsynoservice --restart pkgctl-EmbyServer

Ettől kezdve maga az Emby szerver ténylegesen 8099/8922-n figyel.

2. DSM „meta” és service portok felderítése

SSH-n rootként ellenőriztük, hol fordul elő még 8096/8920 Embyhez kötve:

bashgrep -R "8096" /var/packages/EmbyServer /usr/local/etc/services.d 2>/dev/null
grep -R "8920" /var/packages/EmbyServer /usr/local/etc/services.d 2>/dev/null

Releváns találatok:

text/var/packages/EmbyServer/INFO:adminport="8096"
/var/packages/EmbyServer/target/EmbyServer.sc:src.ports="8096,8920/tcp"
/var/packages/EmbyServer/target/EmbyServer.sc:dst.ports="8096,8920/tcp"
/usr/local/etc/services.d/EmbyServer.sc:src.ports="8096,8920/tcp"
/usr/local/etc/services.d/EmbyServer.sc:dst.ports="8096,8920/tcp"

A többi találat (bináris DLL-ek, hwdata PCI IDs) nem kapcsolódik hálózati portokhoz, azokat nem módosítjuk.

3. Emby csomagmeta és service portok átírása 8099/8922-re

3.1. INFO – adminport

bashnano /var/packages/EmbyServer/INFO

Eredeti sor:

textadminport="8096"

Módosítva:

textadminport="8099"

Ez azt mondja a DSM-nek, hogy az Emby „admin portja” 8099 legyen, ne 8096.

3.2. EmbyServer.sc – target service

bashnano /var/packages/EmbyServer/target/EmbyServer.sc

Eredeti sorok:

textsrc.ports="8096,8920/tcp"
dst.ports="8096,8920/tcp"

Módosítva:

textsrc.ports="8099,8922/tcp"
dst.ports="8099,8922/tcp"

3.3. EmbyServer.sc – global service definíció

bashnano /usr/local/etc/services.d/EmbyServer.sc

Eredeti sorok:

textsrc.ports="8096,8920/tcp"
dst.ports="8096,8920/tcp"

Módosítva:

textsrc.ports="8099,8922/tcp"
dst.ports="8099,8922/tcp"

Ezekkel a módosításokkal:

  • Emby saját configja (system.xml)
  • DSM csomagmeta (INFO)
  • Emby target service definíció (target/EmbyServer.sc)
  • DSM service definíció (/usr/local/etc/services.d/EmbyServer.sc)

mind ugyanarra az új portkészletre (8099/8922) mutat.

4. Emby leállítása / NAS újraindítása

A konfiguráció és metaadat módosítása után:

bashsynoservice --stop pkgctl-EmbyServer
reboot

A NAS újraindítása biztosítja, hogy DSM az új portinformációkat töltse be.

5. Jellyfin csomag telepítése

Újraindítás után:

  • DSM → Csomagkezelési központ → Jellyfin → Telepítés

A portütközés-probléma itt oldódott meg: mivel Emby minden szinten 8099/8922 portokra lett átállítva, Jellyfin csomag telepítője már nem lát 8096/8920-on Embyhez kötött csomagot, így átengedi a telepítést.

Kimenet: Jellyfin csomag sikeresen feltelepült Emby jelenléte mellett, Container használata nélkül.

6. Jellyfin portok átírása (hogy később se ütközzön)

Telepítés után Jellyfin elindítása és admin felület elérése:

texthttp://NAS_IP:8096

Admin → Dashboard → Networking (vagy Advanced → Networking):

  • Local HTTP port: 8096 → pl. 8097 vagy 9096
  • Local HTTPS port: 8920 → pl. 9097 (ha használod)

Mentés, Jellyfin csomag restart.

Ettől kezdve Jellyfin stabilan az új portokon fut, függetlenül az Emby konfigurációjától.

7. Mi lesz Embyvel a Jellyfin telepítés után?

Miután Jellyfin portjait átállítottuk, és Jellyfin stabilan új portokon fut:

  • Emby maradhat 8099/8922-n – ez a legbiztonságosabb, mert így fizikailag sem „néz rá” Jellyfin portjaira.
  • Elméletben Embyt vissza lehetne állítani 8096/8920-ra is, de akkor ismét oda kell figyelni, hogy Jellyfin ne használja ugyanazokat a portokat.

A DSM oldali metaadat-módosítások (INFO, EmbyServer.sc) frissítésnél visszaállhatnak gyári értékre, ezért hosszú távon nem célszerű „végleges megoldásként” tekinteni rájuk – ebben a tesztben kifejezetten arra szolgáltak, hogy Jellyfin csomag telepítése átmenjen.

Mit bizonyít ez a lab teszt?

  • Megmutatja, hogy technikai szinten DSM 7-en is összehozható csomagos Emby + csomagos Jellyfin párhuzamosan ugyanazon NAS-on, ha:
    • Emby portjait minden szinten átírjuk (runtime + meta + service),
    • Jellyfin feltelepül default portokon,
    • majd Jellyfin portjait átállítjuk saját, ütközésmentes értékekre.
  • Egyben azt is jelzi, hogy ez a megoldás:
    • nem hivatalosan támogatott,
    • DSM frissítések és csomagfrissítések érinthetik,
    • csak tapasztalt rendszergazdának ajánlott, labor környezetben.

Így a blog eredeti következtetése (hogy production környezetben Emby csomag + Jellyfin konténer kombináció stabilabb, mint két csomag egymás mellett) továbbra is érvényes, de most van hozzá egy dokumentált „proof-of-concept” lab szekció, hogy megfelelő hekkeléssel csomagos Emby + csomagos Jellyfin is összehozható.

Nincsenek hozzászólások

Hogyan integráltam az UptimeRobotot a Synology tűzfallal úgy, hogy a biztonság is megmaradjon

  Szerző: ,

Régi problémám volt, hogy a Synology NAS-okon szigorú, ország alapú (GeoIP) tűzfalat használok, miközben az UptimeRobotnak is el kell érnie a DSM webfelületét és pingelnie kell a szervert. Ez elsőre ellentmondásnak tűnik: hogyan engedjek be egy rakás külföldi IP-t úgy, hogy közben a tűzfal továbbra is mindent tiltson, ami nem kell?

Ebben a bejegyzésben leírom, hogyan oldottam meg ezt két Synology NAS-on (köztük egy DS220+ készüléken), úgy, hogy:

  • az UptimeRobot minden monitorja stabilan zöld marad,
  • a DSM tűzfal továbbra is csak Magyarországról (és adott esetben még néhány országból) enged be forgalmat,
  • a megoldás reboot-álló, azaz újraindítás után automatikusan visszaállnak a szabályok.

Kiindulási helyzet: DSM tűzfal, GeoIP és UptimeRobot

A DSM beépített tűzfala alapból jól használható, de két fontos korlátja van:

  • Nem kezel IP-listákat dinamikusan (pl. UptimeRobot IP-k hosszú listája).
  • Reboot vagy Docker indulása után a belső iptables struktúrák változhatnak, ezért ha kézzel piszkáljuk, az nem tartós.

A saját NAS-aimon a tűzfal úgy néz ki, hogy az egyedi láncok (INPUT_FIREWALL, FORWARD_FIREWALL) végén van egy olyan szabály, ami csak bizonyos országkódokat enged (pl. GB,HU), utána pedig egy végső DROP. Ez szuper biztonságos, de az UptimeRobot szerverei jellemzően több országból, különböző IP-tartományokból érkeznek.

A cél tehát az volt, hogy:

  • Az UptimeRobot IP-k kapjanak RETURN szabályt a lánc elején (icmp + TCP 5000/5001),
  • Minden más csak a GeoIP-szabályon keresztül mehessen,
  • Ezeket a plusz szabályokat automatikusan visszatöltsük minden reboot után.

1. UptimeRobot IP-k beépítése a mentett iptables szabályokba

Először kellett egy stabil, „referencia” iptables konfiguráció, amibe bele lehet injektálni az UptimeRobot IP-ket.

A lépések nagy vonalakban:

  1. Készítettem egy mentést a jelenlegi iptables szabályokról egy fájlba (fw-before-uptimerobot.rules).
  2. Ebbe a fájlba, a *filter táblán belül, az INPUT_FIREWALL és FORWARD_FIREWALL lánc végénél beszúrtam az UptimeRobot kommenteket és a hozzájuk tartozó szabályokat, például:bash# UptimeRobot – 3.12.251.153 -A INPUT_FIREWALL -s 3.12.251.153/32 -p icmp -j RETURN -A INPUT_FIREWALL -s 3.12.251.153/32 -p tcp -m multiport --dports 5000,5001 -j RETURN -A FORWARD_FIREWALL -s 3.12.251.153/32 -p icmp -j RETURN -A FORWARD_FIREWALL -s 3.12.251.153/32 -p tcp -m multiport --dports 5000,5001 -j RETURN Ugyanez a minta ismétlődik végig az összes UptimeRobot IP-re.
  3. Ügyeltem rá, hogy ezek a szabályok a GeoIP RETURN és a DROP elé kerüljenek, hogy az UptimeRobot sose essen bele a tiltásba.

Ezzel lett egy „golden” rules fájlom (fw-uptimerobot-stable.rules), amiben a filter tábla már tartalmazza az UptimeRobot számára szükséges engedélyeket.

2. Csak a filter tábla kivágása: fw-uptimerobot-filter.rules

Nem akartam az egész iptables állapotot visszatölteni, csak a filter táblát, azon belül is a saját láncokat érintő részeket. Ehhez egy egyszerű awk parancsot használtam, amivel a *filter és a hozzá tartozó COMMIT közötti rész került egy külön fájlba:

bashawk '
  $0 ~ /^\*filter/ {p=1; print; next}
  $0 ~ /^COMMIT/ && p==1 {print; exit}
  p==1 {print}
' /root/fw-uptimerobot-stable.rules > /root/fw-uptimerobot-filter.rules

Ellenőrzésként egy head és egy tail:

bashhead -n 20 /root/fw-uptimerobot-filter.rules
tail -n 20 /root/fw-uptimerobot-filter.rules

A végeredményben:

  • fent látszanak a láncdefiníciók (:INPUT_FIREWALL - [0:0], stb.),
  • lent a sok # UptimeRobot – ... komment és a hozzájuk tartozó -A INPUT_FIREWALL / -A FORWARD_FIREWALL sorok,
  • végén a GeoIP szabály és a DROP.

3. restore-iptables.sh: a varázsscript, ami mindent visszaállít

A kulcs a tartóssághoz egy kis shell script lett, amelyet a NAS bootolás után automatikusan futtatok. A script feladata:

  • várni egy kicsit, amíg DSM és Docker teljesen feláll;
  • kiüríteni az INPUT_FIREWALL és FORWARD_FIREWALL láncokat;
  • soronként visszatölteni csak azokat a szabályokat, amelyek ezekre a láncokra vonatkoznak (beleértve az UptimeRobot IP-ket).

A script tartalma:

bash#!/bin/sh

# 120 mp várakozás, hogy DSM + Docker felálljon
sleep 120

RULES_FILE="/root/fw-uptimerobot-filter.rules"

if [ -f "$RULES_FILE" ]; then
    # 1) Kiürítjük a saját láncokat az élő táblában
    /sbin/iptables -F INPUT_FIREWALL
    /sbin/iptables -F FORWARD_FIREWALL

    # 2) Csak az INPUT_FIREWALL / FORWARD_FIREWALL sorokat adjuk hozzá soronként a mentett rules-ból
    grep '^-A INPUT_FIREWALL '   "$RULES_FILE" | while read line; do /sbin/iptables $line; done
    grep '^-A FORWARD_FIREWALL ' "$RULES_FILE" | while read line; do /sbin/iptables $line; done
fi

exit 0

A scriptet elmentettem ide:

bash/usr/local/bin/restore-iptables.sh
chmod +x /usr/local/bin/restore-iptables.sh

Kézi teszthez csak futtatni kell:

bash/usr/local/bin/restore-iptables.sh &

A sleep 120 miatt kell egy kis türelem, de utána az iptables -L INPUT_FIREWALL -n -v | head és az iptables -L FORWARD_FIREWALL -n -v | head már szépen mutatja az UptimeRobot IP-ket a láncok elején.

4. Automatizálás: DSM Feladatütemező

Hogy rebootok után is minden magától helyreálljon, a DSM Feladatütemezőben hoztam létre egy új feladatot:

  • Típus: Felhasználó által megadott script.
  • Futó felhasználó: root.
  • Ütemezés: Indításkor (system boot után).
  • Parancs:bash/usr/local/bin/restore-iptables.sh

Nem kötelező a &, mert a scriptben benne van a sleep 120, ettől függetlenül a rendszer ettől nem „akad meg”, a feladat simán lefut a háttérben.

Ezt a megoldást több NAS-on is ugyanazzal a logikával alkalmaztam (köztük egy DS220+), így mindenhol egységes:

  • UptimeRobot gond nélkül éri el a NAS-t pinggel és a DSM portokon,
  • a GeoIP-alapú ország szűrés és a többi tűzfalszabály változatlanul éles,
  • reboot után sem kell kézzel „igazítani” az iptables beállításokon.

Összegzés

Ez a megoldás egy praktikus kompromisszum a monitorozhatóság és a biztonság között:

  • A DSM saját tűzfalát használja, nem „tapossa szét” a Synology logikáját.
  • Az UptimeRobot IP-k külön, átlátható blokkban vannak, könnyen frissíthetők.
  • A restore-iptables.sh és a Feladatütemező gondoskodik arról, hogy az egész konfiguráció tartós legyen.

Ha te is erősen szűrt, GeoIP-alapú tűzfalat használsz Synology NAS-on, és közben szeretnéd UptimeRobottal monitorozni a DSM-et (ping + webfelület), ez a módszer bevált, stabil és viszonylag egyszerűen karbantartható.

Nincsenek hozzászólások

Synology: DSM 7.2.2-72806 4. frissítés

  Szerző:

On July 25, 2025, Synology released a new DSM version called DSM 7.2.2-72806 Update 4.

Version: 7.2.2-72806 Update 4

(2025-07-24)

Important notes

  1. Your Synology NAS may not notify you of this DSM update because of the following reasons. If you want to update your DSM to this version now, please click here to update it manually.
    • The update is not available in your region yet. The update is expected to be available for all regions within the next few days, although the time of release in each region may vary slightly.
    • Your DSM is working fine without having to update. The system evaluates service statuses and system settings to determine whether it needs to update to this version.
  2. This update will restart the device.

Fixed Issues

  1. Fixed a security vulnerability regarding SDK library (CVE-2025-8024).
  2. Fixed multiple security vulnerabilities.

Nincsenek hozzászólások

Mi a teendő, ha „a fájl használatban van, vagy a hozzáférés megtagadva” üzenet jelenik meg a Synology Drive Client szinkronizálása közben?

  Szerző:

„A fájl nem szinkronizálható, mert használatban van, vagy a hozzáférés megtagadva” üzenet jelenik meg a Synology Drive Clientben végzett fájlok szinkronizálása közben.

1.png

Módosítsa a fájl vagy mappa engedélybeállításait a számítógépen

A fájlok vagy mappák nem szinkronizálhatók, ha más alkalmazások használják őket, vagy ha nem rendelkezik megfelelő jogosultságokkal. Próbálja ki a következő módszereket a probléma megoldásához.

Windowshoz

  • Kattintson a jobb gombbal a fájlra vagy mappára a Windows Fájlkezelőben, válassza a Tulajdonságok lehetőséget , törölje a jelet a Csak olvasható jelölőnégyzetből, és próbálja meg újra a szinkronizálást.
  • Győződjön meg arról, hogy jelenlegi Windows felhasználói fiókja teljes írási-olvasási engedéllyel rendelkezik a Synology Drive Client helyi mappájához. A mappa engedélybeállításainak módosításához tekintse meg ezt a cikket . 1
  • A LockHunter segítségével megtudhatja, melyik alkalmazás használja a fájlt. Letöltheti és többet megtudhat a LockHunterről a webhelyéről .

Machez

  • Győződjön meg arról, hogy jelenlegi Mac felhasználói fiókja teljes írási-olvasási engedéllyel rendelkezik a Synology Drive Client helyi mappájához. A mappa engedélybeállításainak módosításához tekintse meg ezt a cikket .
  • Győződjön meg arról, hogy a Synology Drive Client teljes lemezhozzáférési engedéllyel rendelkezik a Rendszerbeállítások > Biztonság és adatvédelem > Adatvédelem > Teljes lemezhozzáférés menüpontban .
    2.png

Ubuntuhoz

  • Győződjön meg arról, hogy jelenlegi felhasználói fiókja teljes írási-olvasási engedéllyel rendelkezik a Synology Drive Client helyi mappájához. A mappa engedélybeállításainak módosításához tekintse meg ezt a cikket .

Adja hozzá a Synology Drive Client programot a víruskereső program engedélyezési listájához

Ha meg szeretné akadályozni, hogy a víruskereső mechanizmusok zárolják a fájlokat, adja hozzá a Synology Drive Client programot és a szinkronizálási mappát a víruskereső program engedélyezési listájához.

Kerülje el ugyanazon fájlok egyidejű szerkesztését a szerveren és az asztali segédprogramban

Egyes alkalmazások zárolhatnak egy fájlt, amikor a fájlt megnyitják és elérik a kiszolgálóról, ami a Synology Drive Client segítségével történő szinkronizálás meghiúsulását okozhatja.

Ha több felhasználónak 2 szeretné engedélyezni, hogy szerkeszthesse ugyanazt a fájlt, amelyet szinkronizálnak, győződjön meg arról, hogy minden felhasználó ugyanarról a csatlakozási módról éri el (pl. csak a Synology Drive Client segítségével vagy csak a szerveren SMB-n keresztül).

Kerülje a folyamatosan elérhető fájltípusok szinkronizálását

Egyes fájlok természetükből adódóan folyamatosan elérhetők, például naplófájlok, virtuális lemezek és adatbázisok. Nem javasoljuk az ilyen fájlok szinkronizálását, mivel a Synology Drive Client segítségével történő szinkronizálás valószínűleg sikertelen lesz. A szinkronizálási probléma elkerülése érdekében próbálkozzon az alábbi módszerek valamelyikével.

  • Számítógépén helyezze át a szinkronizáláshoz nem ajánlott fájltípusokat a szinkronizálási mappából. Alternatív megoldásként válasszon másik helyi mappát a szinkronizálási feladathoz.
  • Állítsa be számítógépén a szinkronizálási szabályokat a Synology Drive Client alkalmazásban.
    1. Nyissa meg Synology Drive Clientjét, lépjen a Feladatok szinkronizálása elemre , válasszon ki egy feladatot, majd kattintson a Szinkronizálási szabályok > Fájlszűrő elemre a kizárt fájltípusok megtekintéséhez. Ha például nem szeretné, hogy az ios fájlkiterjesztés szinkronizálva legyen, írja be a *.ios karakterláncot a beviteli mezőbe, és kattintson a ” + ” gombra, hogy hozzáadja a listához.
      3.png
    2. Nyissa meg a Synology Drive Client alkalmazást, lépjen a Szinkronizálási szabályok > Mappa menüpontra , és jelölje be a Mappaalapú szelektív szinkronizálást . Csak az itt bejelölt mappák szinkronizálódnak.
      4.png
  • A Synology NAS-on állítsa be a felhasználói szinkronizálási profilokat a Synology Drive felügyeleti konzoljában. 3
    • Jelentkezzen be a DSM-be, indítsa el a Synology Drive felügyeleti konzolt, kattintson a Beállítások > Felhasználói szinkronizálási profilok elemre , válasszon profilt, majd kattintson a Szerkesztés gombra . Ha fiókja szerepel az Alkalmazott felhasználók listáján, akkor a profil fájlszűrő szabályai vonatkoznak majd a fiókjára.
      5.png

Lépjen kapcsolatba a műszaki támogatással

Ha a fenti módszerek mindegyike sikertelen, forduljon a Synology műszaki támogatásához . Ehhez be kell jelentkeznie Synology-fiókjába. Ahhoz, hogy a Synology diagnosztizálhassa a problémát, győződjön meg arról, hogy tartalmazza a rendszernaplófájljait, a Synology Drive Client naplóját, valamint körülbelül 1-5 olyan fájl elérési útját és fájlnevét, amelyek nem szinkronizálhatók.

A Synology NAS rendszernaplófájlok beszerzése:

  1. Jelentkezzen be a DSM-be a rendszergazdák csoportjához tartozó fiókkal.
  2. Lépjen a Főmenü > Támogatási központ > Támogatási szolgáltatások menüpontra .
    • DSM 5.x és 6.x esetén: A Napló generálás alatt jelölje be a Rendszer és Synology Drive Server jelölőnégyzetet , kattintson az Alkalmaz gombra , majd kattintson a Naplók generálása elemre .
    • DSM 7.0 és újabb verziók esetén: A Napló generálás alatt jelölje be a Synology Drive Server jelölőnégyzetet , kattintson az Alkalmaz gombra , majd kattintson a Naplók generálása elemre .

Synology Drive Client naplók beszerzése:

  1. Számítógépén nyissa meg a Windows rendszertálcáját vagy a Mac menüsorát, és kattintson egyszer a bal gombbal a Synology Drive Client ikonra. Kattintson a jobb alsó sarokban lévő ellipszisre, és lépjen a Hibaelhárítás > Diagnosztikai napló exportálása menüpontra .
  2. A naplók lekéréséhez kattintson az Exportálás gombra . Alapértelmezés szerint a naplók a letöltési mappába kerülnek.
Nincsenek hozzászólások

Synology Photos Mobile Widget iOS-en

  Szerző:

A Photo Widget beállítása

A fénykép widget segítségével újraélheti emlékeit telefonja kezdőképernyőjén.

Fotó widget létrehozása:

  1. Érintse meg hosszan a kezdőképernyőt. Koppintson a Szerkesztés > Widget hozzáadása elemre .
  2. Keressen a Photos Mobile alkalmazásban , és adja hozzá a fénykép widgetet.
  3. Kövesse a varázslót a megfelelő widgettípus és megjelenítendő album kiválasztásához.
  4. Érintse meg a Widget hozzáadása lehetőséget , hogy hozzáadja a kezdőképernyőhöz.

Ha a későbbiekben módosítani szeretné a widget beállításait, érintse meg és tartsa lenyomva a widgetet.

Jegyzet:

Nincsenek hozzászólások

Nézze meg a kötethasználatot

  Szerző:

A Használati részletek valós időben jeleníti meg a kötethasználatot. Az információk alapján meghatározhatja, hogy mely szolgáltatások foglalják el a legtöbb helyet, és olyan műveleteket hajthat végre, mint például a szükségtelen fájlok eltávolítása vagy a kötet méretének bővítése.

Mielőtt elkezded

  • A használati részletek csak a Btrfs fájlrendszerben lévő köteteknél engedélyezhetők.
  • A használati adatok csak akkor engedélyezhetők (vagy tilthatók le), ha a kötet az alábbi állapotok valamelyikében van:
    • A kötet állapota Egészséges.
    • A kötet állapota Figyelmeztetés , mert nincs elegendő kapacitás.
  • A használati részletek alapértelmezés szerint engedélyezve vannak a DSM 7.0 és újabb verziójában létrehozott köteteknél. Ha a kötetet egy korábbi DSM-verzióban hozta létre, manuálisan kell engedélyeznie ezt a lehetőséget, miután frissítette a rendszert a DSM 7.0-ra.

Engedélyezze és tekintse meg a használati részleteket

A kötet használati adatainak engedélyezése:

  1. Nyissa meg a Tárhelykezelő > Tárhely menüpontot.
  2. Kattintson a konfigurálni kívánt Btrfs-kötet jobb felső ikonjára.
  3. Válassza a Beállítások lehetőséget.
  4. Lépjen a Használati részletek szakaszba, és jelölje be a Használati részletek elemzésének engedélyezése jelölőnégyzetet.
  5. A megerősítéshez kattintson a Mentés gombra.

Jegyzet:

  • A használati adatok engedélyezése átmenetileg befolyásolhatja a rendszer teljesítményét. Például a rendszer teljesítménye 3–10%-kal csökkenhet a releváns szolgáltatások mennyiségi felhasználásának elemzésekor.

Egy kötet használati adatainak megtekintéséhez:

  1. Nyissa meg a Tárhelykezelő > Tárhely menüpontot.
  2. Kattintson a megtekinteni kívánt Btrfs-kötet jobb felső ikonjára, és válassza a Használati részletek lehetőséget.
    Megjegyzés: A Használat részletei lehetőség csak akkor kattintható, ha a kötet a „Mielőtt elkezded” részben említett állapotban van.
  3. A Használati részletek ablakban megtekintheti a kötet teljes és elérhető kapacitását, valamint a használat szolgáltatásonkénti bontását. Ezek a szolgáltatások magukban foglalják:
    • Megosztott mappa
    • Hibrid megosztási mappa
    • LUN/VMM
    • Synology Drive adatbázis
    • Pillanatkép
    • Egyéb (pl. rendszer- és csomagkonfigurációs fájlok és felhasználói adatok)