-
Fototrend
Új hozzászólás Aktív témák
-
lovi27
addikt
válasz
Celtis
#15164
üzenetére
Én a Portainerben menedzselem a dockert. Ha már nincs szükség egy konténerre, a Containers menüben ki kell választani a konténert és a Remove gombbal kitörölni. Ilyenkor ajánlott megnézni az egyéb hozzátartozó dolgokat is (pl.: volume, image, network, stb.) és azokat is kitörölni, hogy ne maradjon szemét. Ha a Stacks menüben volt telepítve a konténer, akkor a forrást is, a docker-composet ha később szükség lehet rá, ajánlott fájlba kimenteni.
Nem kellenek. Egyszerre csak egyet használ, a legújabb verziót. Gondolom, ezek a linuxserver image-k amelyek jelenleg két címről is letölthetők.
#15165 Celtis
Én nem ajánlottam SMB-t az LG tévéhez, csak DLNA szervet. Azt is azért, mert a társ még új az OMV-ben és a plugint könnyebb telepíteni. -
lovi27
addikt
válasz
lovi27
#15159
üzenetére
Ha valaki nem tudná, a docker a normál, Linux frissítési úton frissül, viszont a Portainer nem.
Azt vagy az Extrák menüben a Portainer telepítése gombra kattintva frissíti magát a legújabb verzióra (v2.1), vagy aki használ watchtower vagy hasonló verzió frissítő konténert, annak az megteszi helyette. -
lovi27
addikt
válasz
Balerik
#15152
üzenetére
Az LG TV alapból a DLNA protokollt használja és a PLEX-et is csak mint DLNA szerver látná. Viszont a pluginok közt van 'csak' DLNA szerver is, a MiniDLNA.
Megéri kipróbálni. Egyszerűbb telepíteni, beüzemelni és ha nem váltja be a reményt, még mindig ott lesz a Plex szerver telepítése. -
#15149
lovi27
addikt
tradeelek11
#15143
lovi27
addikt
válasz
tradeelek11
#15143
üzenetére
A kedvedért kipróbáltam és jól működik úgy ahogy a szerzők javasolják a leírásban.
Természetesen nem követtem a rossz tanácsodat, mert akkor nem csoda ha a szegény Portainer azt se tudja mit csináljon és esetleg veszettül keresgél az image-k között. ![;]](//cdn.rios.hu/dl/s/v1.gif)
A példádnál maradva, ha meg akarod változtatni a Restart policy-t a forrást szerkeszd. Abban változtasd meg és telepítsd (Deployment) újra a konténert. Különben más állapot lesz a konténerben mint amit a stack/editor mutat, és ez nem normális. Később csak kavarodás lenne belőle, mert mindenki a docker-compose-t nézné meg a stack-ban, hogy mit tartalmaz a konténer. Megnéztem a fórumukat is és ott se panaszkodott senki arra amit írtál.
Különben a ghcr-től nem kell félni, a github container registry rövidítése. Nekünk mindegy, de a GitHub-on kialakítottak tárhelyet docker images számára és a linuxserver majd oda akarja költöztetni a dolgait.
-
#15142
lovi27
addikt
tradeelek11
#15140
lovi27
addikt
válasz
tradeelek11
#15140
üzenetére
Ne írja át senki! Felesleges és nem kell!!
Csak címben különbözik a kettő, az image ugyanaz. A ghcr.io az újabb és majd ezt szánják az elsődleges elérésnek, de jelenleg mindkettő használható. Más különbség nincs közöttük. -
#15100
lovi27
addikt
tradeelek11
#15098
lovi27
addikt
válasz
tradeelek11
#15098
üzenetére
és szpeti40
A személyes tapasztalatok inkább érdekeltek volna, mert olvasni tán tudok.
Amiben egyetértenek, hogy gyorsabb. Biztonságosabb. Ez arra épül, hogy kevesebb kódsort tartalmaz, ergo a hibalehetőség is kevesebb. Rendben, de az OpenVPN-ben eddig nem találtak hibát. Itt inkább nincs különbség, de a rövidsége, egyszerűsége miatt a WG inkább perspektivikus. Szóval, nem tovább ragozva: megér egy próbát!
Viszont, tisztelt fórumtárs, te aki többször kijelentetted, hogy a magánélet védelmében akár a paranoiás jelzőt is vállalod, felhívom figyelmed ezen a téren még az OpenVPN teljesít jobban, ha olyan összehasonlítást nézel ahol nem csak a WG előnyeiről olvashatsz.
-
lovi27
addikt
válasz
stigma
#15089
üzenetére
"...omv-firstaid paranccsal portot változtattam, majdhibára futott és visszanéztem mit ír ki SSH-, középtájt kellett egy fájlból 1 sort kiszednem és ment is..."
Nekem ez így tök zavaros. Értelmezhetetlen.
Úgy gondolom belepiszkálhattál és elrontottál valamit, de akkor az nem érdekes.
Viszont, ha tényleg a frissítés hatására történt valami olyan ami miatt nem tudtál belépni, azt mindenkinek hasznos volna tudni mi volt az. -
lovi27
addikt
válasz
stigma
#15087
üzenetére
Akkor miért kevered ide, miért emlegeted, ha utána jó volt? Akkor nincs köze a hibához, csak összezavarsz mindent. Nem feladni kell, hanem megjavítani. Egy szakember azt csinálja.
Mivel SSH-n hozzáférsz a rendszerhez eléred a log fájlokat. Eléred a konfig fájlokat. Tudod irányítani a dockert, vezérelni a konténereket, a pluginokat. Annyi mindent lehet csinálni.
A frissítés nem teszi tönkre a rendszert! Csak megakaszthat valamit, amit meg kell keresni.
De ha nincs semmi támpont távolról nem lehet többet mondani. -
lovi27
addikt
válasz
allein
#15082
üzenetére
Hogy milyen NAS-t építsünk arra van külön fórum.
Az OMV is egy Linux. Semmi extrát nem kíván. Nem a processzor és a memória mérete a legfontosabb. Amiket használnál többen is egy RPi 4-el megoldják. Szerintem fontosabb egy jól szellőző ház és megfelelő hűtés a HDD-k számára, valamint egy megbízható tápegység.
De megkérlek a részleteket ne itt beszéld meg.
Szívesen várunk vissza amikor majd be kell üzemelni az OMV-t! -
lovi27
addikt
válasz
stigma
#15077
üzenetére
Ne kitalálni próbáld mit csinálok, mert lényegtelen és rendszerint mellé lősz.
De hogy lezárjuk, az OMV GUI-it tettem a 82-es portra, a PM-t a default porton használom.Azt figyelembe kell venni, hogy 1000-ig sok a dedikált port és nem lehet tetszőlegesen garázdálkodni! Figyelni kell rá nehogy egy olyat akarjunk kisajátítani. A 111-el valószínűleg az volt a baj.
Ha nincs üzenet ami segítsen, akkor nem lehet konkrétumot mondani, de az eddigi hibák alapján valószínűleg nálad is az történt, hogy valamelyik könyvtár lezáródott (lock-olt) lett, azaz ott maradt egy lock fájl, amit ki kéne törölni és máris működne. Csak azt kéne tudni melyik az a könyvtár amihez nem fér hozzá - már ha igaz a feltételezés.
-
-
-
lovi27
addikt
válasz
Balerik
#15067
üzenetére
Ha már az Összefoglalóra hivatkoztál:
"Fontos! A különböző beállítások mindig az admin felhasználónévvel végezhetők el.
Az admin egy nem létező, virtuális felhasználó, rendszergazdai jogokkal, aki az OMV beállításait végzi. Az első bejelentkezéskor a jelszó: openmediavault.""Mi lehet a probléma?" Figyelmetlenség.
-
lovi27
addikt
válasz
Celtis
#15053
üzenetére
Érdemes először az Összefoglalót elolvasni, nem a neten kutatni:
"A Windows alapszolgáltatás (SAMBA) beüzemelése
Ehhez menjünk a Szolgáltatások / SMB/CIFS / Beállítások menübe. Itt ne csináljunk mást csak ellenőrizzük, hogy a Munkacsoport-hoz írt név azonos-e a Windows munkacsoport nevével,...."Adtál írási jogot a felhasználónak ahhoz a mappához amit a sambával is megosztottál?
-
lovi27
addikt
Érdekességképpen.
Le volt állítva a Proxy Manager-em, amit tegnap este 9 óra után indítottam újra.
Ez a terhelési diagram. Jól látszik amikor bekapcsoltam történhetett valami más is, futtattam még a watchtower-t. Frissített 5 konténert, de utána egy magasabb nyugalmi terhelési szinttel működik tovább a rendszer. A fene se tudja mire kell ez neki, de nem túl szimpatikus.
Ráadásul tegnap több filmet is megnéztünk, ami egyáltalán meg se jelenik a diagramban annyira nem okoz terhelést. Igaz, olyankor csak lassú fájlátvitel történik, mert dedikált lejátszót használok.Persze tudom, van megoldás csak látszik a kényelemnek, a kellő tudás hiányának ára van.
-
#15029
lovi27
addikt
XxKristof9xX
#15028
lovi27
addikt
válasz
XxKristof9xX
#15028
üzenetére
Az a garancia ahogy írtam, épp nem csinál semmit a letöltő program. Akkor mit barmol szét?
De amúgy sem történt akkora katasztrófa. Ha jól látom csak elvesztetted a seed-eket.
Ha nem nyúltál semmihez a helyükön ott vannak a letöltött fájlok. Visszamásolod letöltéshez a torrenteket. A program észreveszi már ott vannak letöltve, leellenőrzi változott e rajtuk valami és ha nem, újabb letöltés nélkül folytatja a seedelést. Sőt, ha volt megszakított letöltés azt is onnan folytatja. -
#15027
lovi27
addikt
XxKristof9xX
#15026
lovi27
addikt
válasz
XxKristof9xX
#15026
üzenetére
A manuális frissítés csak annyit jelent - már volt róla szó, hogy például nem automatikusan egy beállított időpontban futtatod a watchtowert, hanem egyszeres módban, azaz frissítés után leáll, és a Portainerben kézzel indítod a konténert.
De parancsban is csak ennyi: docker container update
CONTAINERPersze, ez csak egy jó tanács. Mindenki szívassa magát úgy ahogy neki tetszik...
-
#15025
lovi27
addikt
XxKristof9xX
#15023
lovi27
addikt
válasz
XxKristof9xX
#15023
üzenetére
Nem véletlenül hangoztatom, hogy feleslegesek és nem ajánlottak (nem én találtam ki) az automatikus docker frissítések!!
Ezek jellemzően nem biztonsági frissítések mint például a patch keddek a Windowsnál vagy mint az Android havi biztonságiak, hanem funkcionális változtatások. Ha nem követi valaki az új tulajdonságokat, nem tudja kihasználni sem és nem ér semmit a frissítés.
Ráadásul csak úgy megszakítják az adott program működését... Nem kell csodálkozni.A tanulság! Legközelebb manuálosan kell frissíteni és akkor amikor nincs letöltés, nincs seed.
-
-
lovi27
addikt
Meglehet! Nem használom a qB-t a túl agresszív internethasználat miatt, de megnéztem a beállításokat a webes felületen és rögtön ott van amit keresel. Ő Monitored Folder-nek hívja.
Ahhoz hogy elmentse a beállítást a sor végén használd az Add Torrent File jelet.Még annyit, hogy a docker használata miatt nem lehet tetszőlegesen mappákat megadni a programoknak, mert elvileg nem garázdálkodhatnak szabadon. Ezért első próbának ajánlott a szabályokat követni. Hogy utána ez mennyire lesz kiterjeszthető az már más kérdés.
-
lovi27
addikt
Szia! A frissítés nem bántja a meglévő beállításokat. Nekem is még label szerint van minden, ennek ellenére mindig frissítem. De a Fájlrendszereknél a meghajtókat már dev-disk-by-uuid szerint írja ki. Ezt a frissítés cserélhette, én nem. De minden működik!
Volker megerősítette, hogy ezentúl csak uuid szerinti megosztás lesz. Kezdetben is csak az volt. Kikönyörögték a más fajtát, de nem jött be. Visszatértek az eredetihez. -
lovi27
addikt
Most gyorsan csináltam egy telepítést az OMV5-el.
Felelőtlenül a windowsos gépemre úgy, hogy egyik HDD-t és SSD-t sem húztam le. Bíztam a Linuxban, hogy nem cseszi el azokat. USB-ről USB-re telepítettem. Tehát kiírtam az ISO-t egy pendrive-ra és onnan telepítettem egy másik 16GB-os pendrive-ra. Minden probléma nélkül sikerült és a windowsos tárolóimat se bántotta, pedig a grub jelezte, hogy van W10 is.Nem tudom hogyan lehet elrontani. Egyedül akkor kell nagyon figyelni (ha több HDD-van, de a javaslat ugye az, hogy csak egy, a rendszeré legyen), amikor megkérdezi hova telepítse a grub-ot. Azon kívül csak gépnevet és root jelszót kérdez.
Talán azt érdemes megpróbálni, hogy telepítés előtt manuálisan kitörlitek a leendő rendszertároló partícióit.
14985 Kenderice
Az OMV a teljes tárolót törli, ezért csak el kell fogadni az EXT4 és SWAP partíciók létrehozását. Mást nem kérdez. -
#14979
lovi27
addikt
BlackJack21
#14977
lovi27
addikt
válasz
BlackJack21
#14977
üzenetére
Tavaly ősszel volt beragadásos probléma az ftp-vel, azért javasoltam a törlést és újratelepítést remélve kihozza abból az állapotból, de úgy látszik nem elég.
Amúgy nem annyira rossz az a hibaüzenet, mert rákeresve épp olyasmit jelent, hogy a daemon valamiért nem tud elindulni. -
#14974
lovi27
addikt
BlackJack21
#14973
lovi27
addikt
válasz
BlackJack21
#14973
üzenetére
Innen másoltad? [link]
-
lovi27
addikt
válasz
picur10
#14969
üzenetére
Láthatod, a ScoreboardFile-lal van valami baja. Nem találja, esetleg túl régi. Ki tudja.
Nem te hibáztál. Szerintem kezd újra az ftp beállítást, úgyis pillanatok alatt megvan.
Tiltsd le, frissítsd a legújabb verzióra az OMV-t (5.5.22.1), az Extráknál csinálj egy apt tisztítást és indítsd újra az OMV-t. -
-
lovi27
addikt
válasz
ReSeTer
#14937
üzenetére
Ez egy karakter eltérés a két mappa neve között! A hosszuk sem egyezett.
Értsd meg végre nem lehet két azonos nevű mappa ugyanott. Egyik operációs rendszerben se! A számítástechnikában egy bit - mint legkisebb egység - eltérés sem megengedett.A webui portot itt is biztosan meg kell változtatnod, mert az alkalmazás be van zárva a konténerbe. A TZ meg legyen Budapest.
-
#14936
lovi27
addikt
XxKristof9xX
#14934
lovi27
addikt
válasz
XxKristof9xX
#14934
üzenetére
A Plex-ből is talált frissítést, csak az előbb mikor csináltam nem futott a Plex és úgy látszik csak a futó alkalmazásokat frissíti a WT. Ezt is jó tudni. Rendesen megcsinálta.
-
#14935
lovi27
addikt
XxKristof9xX
#14934
lovi27
addikt
válasz
XxKristof9xX
#14934
üzenetére
Most ráengedtem a watchtowert megtalálta azt a qBittorrentet amit mutattál. Az sha256 ugyanaz. Le is frissítette és a régi Image lett unused. Szóval nálam működik rendesen.
Indítsd el manuálisan az alkalmazást és figyeld, hogy legközelebb is ugyanezt csinálja-e.
Vagy gondolom a stackben ott a forrás, így nyugodtan kitörölheted a WT konténert és
hozd létre újra. -
#14933
lovi27
addikt
XxKristof9xX
#14932
lovi27
addikt
válasz
XxKristof9xX
#14932
üzenetére
Ezt használod? containrrr/watchtower
Ha igen, az environment-nél beállítva a Cleanup argument?WATCHTOWER_CLEANUP=trueÉn direkt nem állítom be, mert szeretem látni mi frissült.
Nem gond annál a pár image-nél ami frissült a régit bepipálni és letörölni. -
lovi27
addikt
válasz
Ittnemaz
#14930
üzenetére
Biztos nem az AMD az ok. Torvalds is anno AMD-n dolgozott. Nem véletlenül hívják most is - bár már nem csak azt jelenti - AMD64-nek a Linux 64 bites verzióját.
Véletlenül nem székely vagy? Mire épp elfelejtem miről van szó, akkor jön a válasz tőled.
Próbáltad uninstallálni a plugint, majd újratelepíteni? -
lovi27
addikt
válasz
_Smooth
#14918
üzenetére
Az OMV nyilvántartásában, statisztikáiban csak a pluginnal telepített alkalmazások jelennek meg. Így a dockerrel telepítettek se, mint ahogy a CLI telepítések sem. A docker telepítéseket például ezért segítik a Portainer menedzselő programmal.
Amíg volt Plex plugin az is csak a telepítésben segített, majd a folyamatoknál zöld pötty mutatta, hogy fut vagy sem. Ennyi volt. Az utóbbit a systemctl parancs pótolja.
-
lovi27
addikt
válasz
ReSeTer
#14914
üzenetére
"amit az összefoglalóban találtam, sajnos régi verziót tesz fel"
Tévedés! A CLI telepítés a Debian által tesztelt és jóváhagyott legújabb verziót telepíti. Hogy ez nem mindig az alkalmazásból elérhető legfrissebb kiadás annak biztos oka van, amit a Debian fejlesztőktől lehet megtudni. Amúgy is a p2p protokoll megalkotása óta semmi lényegi változás nem történik, csak aktualizálások. Senki nem marad le semmi fontosról.
-
-
lovi27
addikt
Szia!
Most szüntették meg a label szerinti csatolást. Infóért nem sokat kell visszaolvasnod.Egy mappa megosztásait normálisan meg lehet szüntetni. Ahová eljutottál (config.xml) rossz irány. Nem voltál elég figyelmes és még valahol meg van osztva. A Megosztott mappák menüben ha a Használatban oszlopban majd nem szerepel a mappánál, akkor szüntetted meg az összes megosztását. Ha telepíted a resetperms plugint, akkor a megosztott mappáknál lesz egy új Shared Folder in Use fül ami mutatja hol van megosztva egy mappa.
-
lovi27
addikt
válasz
Ittnemaz
#14899
üzenetére
Megnéztem, az OMV most egy szót ad vissza, de nálam mást:
root@omv5:~# systemctl list-unit-files | grep minidlnaminidlna.service enabledÉs ezt hiányolom nálad, mert abból derülne ki, hogy engedélyezett-e az automatikus indulása. Nálam telepítés után enadled, azaz engedélyezett, tehát indulni fog legközelebb.
Nálad olyan mintha nem jönne meg az eredmény (generated). Generált, de mit?
Most akkor indul vagy nem? Jó vagy nem? -
#14900
lovi27
addikt
meridaharcos
#14898
lovi27
addikt
válasz
meridaharcos
#14898
üzenetére
Igen, arra gondoltam, mert a dockerben az alkalmazások konténerben működnek, oda vannak bezárva és csak az engedélyezett helyeken és módon kommunikálhatnak másokkal.
Ha a dockerben megadtad a portot és nem tudom a qBittorrentben kell-e még kijelölni, engedélyezni, az OMV-ben ezeken felül máshol nem kell.
-
#14897
lovi27
addikt
meridaharcos
#14894
lovi27
addikt
válasz
meridaharcos
#14894
üzenetére
A router topikjában több ember lesz aki tudhatja a beállítást. Az OMV nem korlátozza a portok működését, de a dockerben a használtakat definiálni kell. Gondolom telepítéskor megtetted. Kívülről elérhető vagy? Nem NAT-olt az interneted?
-
lovi27
addikt
válasz
Toninho13
#14891
üzenetére
Ha SSH-n eléred, tudsz vele kommunikálni, akkor parancsokkal meg lehet próbálni, de ehhez egy hozzáértő tanácsa kéne. Valós segítséget a fejlesztők fórumán kaphatsz, de akkor se hiszem, hogy 50%-nál több az esély a megjavításra.
Szerintem gyorsabb megoldás, ha újratelepíted. De a te döntésed.
-
lovi27
addikt
Mielőtt beindul az értetlenkedés miért volt szükséges megszüntetni a /dev/disk/by-label szerinti mountolást, ebben a beszélgetésben elmondja Volker:
-
lovi27
addikt
Szia!
Nem, a docker miatt nem kell újratelepíteni az OMV-t. Sőt, maga a docker sem sérül meg.
A telepített alkalmazások mappáit töröld le, hogy azokat újra hozza létre. A Portaineren belül töröl le a hálózatokat (a három alapot nem lehet és nem is kell), természetesen a konténereket és a létrehozott volumes (könyvtárak) is feleslegesek, ha újrakezded.
Az image-ket vagy letörlöd vagy nem. Nem lényeges. Ha letörlöd úgyis újra letölti ami kell neki, csak úgy érezhetően tovább tart az alkalmazás telepítése. Ha végeztél a nem használt image-ket majd töröld le.A stacks, (vermek) mint forrás nem szükséges törölni, ugyanígy az alkalmazások mappáiban a docke-compose.yml fájlokat se - attól függően honnan telepítettél. Ezek a források amiket feltételezhetően úgyis módosítani szeretnél. De a backuphoz is kiválóak.
Viszont mivel nincs egy docker alkalmazás se, most érdemes megfontolni, hogy nem a rendszerlemezre, hanem valamelyik adat lemezedre helyezed át a docker telepítést ahol több hely áll rendelkezésre és így a telepítésekkel sem íródhat tele a rendszerlemez. Rpi-nél előforduló probléma, ha nem figyelnek rá. Ezt az extra menüben a Docker fülön lehet megtenni, ha az alap tároló cím /var/lib/docker helyett egy saját helyre mutató
abszolút címet adunk meg. -
lovi27
addikt
Eldőlt a by-label kontra by-uuid csatolási probléma: openmediavault 5.5.20
Innentől kezdve csak az UUID szerinti lesz.
-
lovi27
addikt
válasz
vadkörte
#14878
üzenetére
Nem, az fstab-ot nem ajánlott manuálisan módosítani!! Kivétel erősíti a szabályt.
Tegnap találtam erről egy hozzászólást a fejlesztőknél, ahol valaki pont így oldatta meg a problémáját és látszatra működött. De erre írták neki, hogy most működik, de a módosításról nincs tudomása az OMV-nek és ha valamilyen - nem tudom pontosan milyen - rendszer módosítást kap, akkor lehet visszaírja.Idáig végig adat HDD-kről beszéltünk, mert azt kezeli az OMV. Az fstab-ban azokat különíti el. A rendszert - a rendszer és swap partíciót - a Linux kezeli és csatolja fel. Ott nincs szükség variálásra. Ha a rendszert nagyobbra kell cserélni, egyszerűen egy nagyobb tárolóra kell klónozni és a Linuxnak nem lesz gond az új UUID.
Abban meg bízok, hogy a rendszermappákat megosztó plugin nem az UUID alapján, hanem gyökérkönyvtár szerint oszt meg, és ezért nincs is szüksége az UUID-re, így neki mindegy ha megváltozik.Végül is a lényeg, emiatt szerintem se kell újratelepíteni és belakni.
-
lovi27
addikt
válasz
vadkörte
#14875
üzenetére
Oké, jártam így én is.
solyomsherif
Közben megnéztem és ahogy először találkozik az OMV a HDD-vel az lesz az elsődleges azonosítás a csatoláshoz. Ha van label aszerint, ha nincs UUID-vel. És utána már hiába kap címkét a HDD, marad elsődlegesnek az UUID.
De ami ennél is meredekebb, hogy az UUID kicserélhető, mert az "csak egy szám". Egy véletlen azonosítószám. Kicseréltem mind a sima UUID-t, mind a partíció PARTUUID-t, de semmi változás. Meg kell kérdezni a fejlesztőket. Ez még itt nem volt probléma. -
#14872
lovi27
addikt
solyomsherif
#14871
lovi27
addikt
válasz
solyomsherif
#14871
üzenetére
A gányolás alatt pont arra gondoltam, hogy mi hiába írjuk át a rendszerben, az OMV nem vesz róla tudomást. Úgy volna igazi a módosítás, ha onnantól az OMV is aszerint működne.
Amúgy ha működik a label szerinti felcsatolás és újraindításnál sem módosul , szerintem nyugodtan használd úgy, mert nagy galiba nem lehet belőle. Egyrészt ritkán változik az fstab, másrészt ha valamiért mégis megtörténne, akkor ahol addig pl. egy megosztásnál label szerint volt hivatkozva a HDD-re, legfeljebb közli, hogy nem találja. De akkor majd emlékezz rá miért és tudd mit kell korrigálni.
Csak érdekességképpen! Ha volna egy másik HDD jó volna tudni, hogy azt milyen módon csatolja fel. Továbbra is erőlteti-e az UUID-t? Lehet az első felcsatolásnál dől el.
-
#14869
lovi27
addikt
solyomsherif
#14868
lovi27
addikt
válasz
solyomsherif
#14868
üzenetére
Gubancot miért tudna okozna? Csak nekünk, mint embernek nehezebb megjegyezni, nehezebb bánni vele.
-
#14862
lovi27
addikt
solyomsherif
#14861
lovi27
addikt
válasz
solyomsherif
#14861
üzenetére
Nem elrontottál valamit, hanem valószínűleg az OMV valahol megjegyezte, hogy ezt a HDD-t UUID-vel kell felcsatolni. Ezt kéne vele valahogy 'elfelejtetni'. Mert amúgy címkével csatol fel.
Csatold le és állítsd le az OMV-t, majd húzd le a HDD-t. Indítsd újra és állítsd le. Megint csatlakoztasd a HDD-t és hátha már nem foglalkozik a régi állapottal és labellel csatolja fel.
Ha mástól nem jön jobb ötlet, az /etc/fstab fájlban vannak a csatolások, ott átírható, de ez már gányolás és veszélyes is, nem szeretem. Előtte feltétlenül csinálj mentést a fstab-ról!
Ez az OMV szekcióban van, ő csatolja fel és lehet az OMV iniben is tárolja valahol és abban is át kéne írni. De ebben túl sok a feltételezés... -
#14860
lovi27
addikt
tradeelek11
#14859
lovi27
addikt
válasz
tradeelek11
#14859
üzenetére
Azért fórum, mert mást is érdekel a megoldás, más is tanulhat belőle.
Amúgy a volume-k nem jól vannak megadva és az időzóna városa Budapest. -
lovi27
addikt
válasz
Cyrus22
#14854
üzenetére
Nagyon rossz módszer csak úgy a konfig fájlok módosítgatása. Csak akkor kéne ha már nincs OMV módszer rá. Én nem nyúltam egyikbe se. A Transmission volt az első mivel megszűnt a plugin.
Felcsatoltad a winchit? Megosztottad róla a töltendő mappát? A dockeres qbittorrent felhasználónak van joga írni oda? Ha ezekre mind igen a válasz megpróbálnám a qbt docker telepítőnél - gondolom a linuxserver compose az - a volume-khez ezt is hozzáadni, vagy cserélni az eredetit erre.
-
lovi27
addikt
válasz
Ittnemaz
#14852
üzenetére
Szerintem kéne indulnia, de mivel nem használom nincs tapasztalatom.
Mint root lépjél be egy terminálba és nézd meg erre mi a válasz:
systemctl list-unit-files | grep minidlna
Valami hasonló válasz lesz:
minidlna.service generated disabled/enabledRemélem a disabled (tiltott) lesz ott, és akkor mégis csak van egy parancs amit nem próbáltál, mert akkor az meggyógyítja (a kedélyedet is):
systemctl enable minidlna.service -
-
lovi27
addikt
válasz
gabor0828
#14842
üzenetére
Az Összefoglalót elolvastad?
Nagy káosz lehet nálad. Jobban járnál, ha újrakezdenéd és amíg nem megy a samba megosztás a Windowszal, addig az Extrákat sem kéne feltenni vagy legalább ne nyúlj hozzá.
Az alapdolgokhoz (megosztott mappák, felhasználók, SMB, FTP, stb.) nincs szükség rá.Ha már az OMV-t választottad igyekezz mindent azzal megoldani amit lehet.
-
lovi27
addikt
válasz
laracroft
#14838
üzenetére
Nem kell újra leírnom, mert az egy mások megoldás volt.
Ez egyszerű megoldás, de két kiegészítés hozzá:
Az egyik az, hogy mi a démont használjuk, ezért nekünk a transmission-daemon.service fájlban kell hozzáadni a késleltetést.A másik pedig, hogy mint a gyógyszereknél itt is van mellékhatás. Ha ezek után bármikor újraindítjuk a démont a késleltetés feleslegesen, de benne lesz. Ki kell várni. Ezért érdemes a lehető legkisebbre állítani úgy, hogy újraindításkor még elérje célját.
-
lovi27
addikt
válasz
laracroft
#14834
üzenetére
Jó kérdés. Soha nem csináltam olyat, hogy ment a letöltés és közben újraindítottam a NAS-t. Megvártam míg befejezi. Igaz, ritkán töltök le, ráadásul napi 24 órában megy a NAS.
A neten rákeresve másnak is volt hasonló problémája, de nem találtam rá egyértelmű megoldást. Majd kipróbálom.
-
#14819
lovi27
addikt
tradeelek11
#14817
lovi27
addikt
válasz
tradeelek11
#14817
üzenetére
Múltkor kíváncsiságból részt vettem egy Linux tanfolyam, Ubuntu telepítése profi által vagy valami hasonló címe volt. Úgy kezdte az előadó, hogy na akkor most dobjuk a kukába a telepítő CD-t. Köszönöm - mondtam erre - akkor én mit keresek itt?!
Viccet félretéve, mindent paranccsal csinált. Mindent csak azzal oldott meg. Fantasztikus a Linux egy hozzáértő kezében. Hajdan nagyon elsült a Torvalds agya.
-
lovi27
addikt
válasz
tszabi
#14809
üzenetére
Csak még egy kicsit legyetek türelemmel. Talán ma később, de holnap mindenhogy szeretném az Összefoglalóban közzétenni a Transmission, majd utána a qBittorent parancssoros CLI telepítését, mert egyszerű letöltő, megosztó NAS-hoz tényleg felesleges lehet a docker betanulása.
Addig is különös magyarázat nélkül a Transmission telepítése terminálban root joggal:
apt install transmission-daemon
paranccsal, majd a
systemctl stop transmission-daemon
paranccsal állítsd meg daemont és a nano szövegszerkesztőben nyisd meg
nano /etc/transmission-daemon/settings.json
konfig fájlt és benne a következőket módosítsd:
"download-dir": "-------", --> a download könyvtár teljes elérési útvonala!!!
"rpc-password": "------------", --> a webes bejelentkezéshez (egyszerű szöveg)
"rpc-username": "------------", --> ugyanaz
"rpc-whitelist-enabled": false,
"umask": 2,
A módosításokat mentsd el és indítsd újra a daemont:
systemctl start transmission-daemon
A download könyvtárat a Megosztott mappák / ACL menüben tedd az új debian-transmission
csoport tagjává, hogy tudja írni a Transmission!!
Végül egy böngészőben a http://<IP cím>:9091 helyi címen éred al a Transmissiont.Ha valami kimaradt kérdezz nyugodtan, ha még kellett plusz beállítás, kérlek írd meg!
-
#14805
lovi27
addikt
tradeelek11
#14804
lovi27
addikt
válasz
tradeelek11
#14804
üzenetére
A dd parancs. Megnéztem, elfogadja az OMV, tehát telepítve van, de azt olvastam róla, hogy veszélyes parancs, mert akár a forrást is lehet vele törölni, ha rosszul paraméterezik.
Inkább használd valamelyik klónozó programot. -
lovi27
addikt
válasz
akipapi
#14801
üzenetére
Szia! Kezdem a végén. Felesleges a harmadikat belegyúrni! Nem kell állandóan törölgetni!
Ha a felhasználó root akkor nem kell a sudo.
Az OMV szerver operációs szoftver. Szervereket pedig nem frissítenek automatikusan!!
Az asztali Linux frissül automatikusan, tehát nem műszaki a probléma, hanem a fejlesztők tudatosan nem csináltak hozzá automatikus frissítést. Küldenek jelzést amikor van és a rendszergazda majd tudja mikor nem okozhat kárt a frissítéssel.
Meg kell próbálni legalább egy kicsit rendszergazdaként viselkedni. Hasonló a helyzet a watchtower-rel. Ott is leírják, hogy lehetőleg ne használjuk. Hiába.
-
lovi27
addikt
válasz
Gabesz87
#14799
üzenetére
Mindegyikre gondoltam, nem csak amiket említettél.
Ezek a Backports kernel miatt jelenhetnek meg, és ezek az azok által támogatott hardverek lesznek. A Linuxban ha kicserélsz egy hardver elemet nem kezd el rinyálni, mint a Windows, hanem telepíti hozzá az új drivert és megy minden tovább mint addig.
Viszont sajnos kevesebb gyártót támogat. -
lovi27
addikt
-
lovi27
addikt
-
lovi27
addikt
válasz
stigma
#14749
üzenetére
Szóval, jobban tudod mit csináltam, mint saját magam. Rendben! Már annyi mindent olvastam a fórumon. Ez is belefér.
Nincs VPN a Nextcloudhoz, de nem használom élesben. Egyszerűen: nextcloud.domain.com
Ha van megoldásod rá miért titkolod azoktól akik bíznak benned? Miért hiányzik a "végleges" leírásból? (Te címezted így!) Jól hangzik a "hivatalos" duma, de akkor azt is mellé kéne tenni, hogy milyen hátrányokkal jár a használata. Pontosabban mi hiányozik még ahhoz, hogy használható legyen. Ők leírták.
Amúgy, más image készítő is az official image-t használja, az az alap, csak kiegészítik olyan beállításokkal amit mókolásnak hívsz. Ha megcsinálják helyettünk akkor miért mi kínlódjunk? Aki meg szeret mindent maga beállítani az telepítsen parancsokkal, mert úgy az igazi!
Ezért szeretem a linuxserver.io megoldásait, mert úgy vettem észre csak olyan apróságokban tér el az offical megoldástól, hogy utólag nekünk ne kelljen mókolni vele. -
#14780
lovi27
addikt
tradeelek11
#14775
lovi27
addikt
válasz
tradeelek11
#14775
üzenetére
Mobilod sincs? Vagy az nem zavar, hogy tudják mikor indulsz, mikor érkezel, merre jársz, mennyi ideig hol tartózkodol?
-
lovi27
addikt
válasz
Gabesz87
#14772
üzenetére
Valaki vagy valami DDNS-t játszik...
Na, közben ezt találtam: Xiaomi Mi Robot vacuum cleaner hacked
Most ez ne ijesszen meg, mert végül is dicsérik a Xiaomi biztonsági megoldását.
Ez a DDNS valami a Xiaomi Cloud. Az a közös kapcsolódási felület.Míg olvastam megelőztek, de az eredmény ugyanaz.
-
#14771
lovi27
addikt
kissjani85
#14769
lovi27
addikt
válasz
kissjani85
#14769
üzenetére
Lehet, nálad is a root filesystem is full?
Na, akkor erre oda kell figyelmi! Szép új docker világ.
-
lovi27
addikt
válasz
Gabesz87
#14767
üzenetére
Nem elég. Ha nem tudják hol van a NAS, hol elérhető akkor hogy találják meg? Az interneten az IP cím a lakcím. Ehhez egy állandó elérhetőség kell (ez fix IP), amiért fizetni kell és ezért a legtöbb embernek nincs ilyenje.
Vagy kell egy olyan szolgáltató aki ad ingyen egy állandó elérhetőséget és "figyeli" a te változó IP címed és mindig utánad küldi a kérést, oda ahol épp tartózkodol (az aktuális IP-re).
Az a DDNS szolgáltatás. Valamelyik kell. És persze a kapcsolat csak titkosítva van valamennyire biztonságban, így titkosítás is kell! -
lovi27
addikt
válasz
GeGexx
#14760
üzenetére
"Gondolom előszeretettel keresik és törik fel az ilyen kis házi ták szervereket."
Rosszul gondolod! A hackerek szakmailag igen képzett, céltudatos emberek, akik a semmire nem pazarolják az időt és az energiát. Szinte mindig oka van miért törtnek be egy szerverbe. Ma már a 'gagyi' szerverek is védettek a jelszó feltörés ellen, azaz nagyon korlátozott a próbálkozások száma. Ezért ajánlanak erős jelszót, ami gyakorlatilag feltörhetetlen. Persze, ha például nem megfelelőlen titkosítják akkor lehet akármilyen erős.
Azért írtam szinte mindig oka van, mert van eset amikor ráér, unatkozik a hacker és mivel képes rá, gondolja "miért ne ha megtehetem" alapon választ egy szervert. A rossz helyen, rossz időben tipikus esete. Ez az egy ok amivel mindenki célkeresztbe kerülhet, de ezen kívül csak nyomós okokról olvashatunk. De akkor se feltörésről, hanem kivétel nélkül vagy a szerverre juttatott kénprogrammal vagy a jelszó kicsalásával történik a behatolás.
-
lovi27
addikt
Akkor azt nem a Portainer, hanem a qBittorent logja mutatta! De a qBittorrent be van zárva egy konténerbe, amit belsőleg nem tud megváltoztatni. Ez a Docker egyik lényege! És ha megnézted volna mit mutat a Portainer a konténereknél, akkor láttad volna a qBittorrentnél, hogy neki nem a 8081-es port az engedélyezett.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Természetesen nem követtem a rossz tanácsodat, mert akkor nem csoda ha a szegény Portainer azt se tudja mit csináljon és esetleg veszettül keresgél az image-k között. 
Új hozzászólás Aktív témák
Figyelem!
Megjelent a Debian 10-re épülő OMV 5 stabil kiadása.
Új telepítésre ez a verzió ajánlott.
- 10 Darab ÚJ PC Játékszoftver
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - 15% AKCIÓ
- Game Pass Ultimate előfizetések 1 - 36 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN! AKCIÓ!
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Lenovo ThinkPad P15 Gen 1 Intel i7-10875H 32GB 1000GB Nvidia Quadro RTX 3000 1 év garancia
- Cisco Catalyst C1000-48T-4G-L 48xRJ45 4xSFP switch, CISCO refurbished
- 152 - Lenovo LOQ (15IRH8) - Intel Core i5-12450H, RTX 4060
- Újszerű Apple Macbook Air 13 - M2 - 8/256GB (MLY33MG/A) éjfekete - 141 Ciklus - 1+ év garancia - HUN
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi