-
Fototrend
Új hozzászólás Aktív témák
-
tama777
tag
válasz
lovi27
#15569
üzenetére
Jogos, legközelebb (ha nem felejtem el) figyelek erre! Viszont nem általánosságban írtam erről, hanem a nála jelentkező hibára reagálva, így _q fórumtársnak lett címezve a megoldás! Amikor valakinek írok, általában visszaolvasok pár hozzászólást, hogy "képbe" legyek a dolgokkal: #15533 hozzászólásában ezt írta: "a raspberryn pedig 32 bit-es linux van ". Tehát vagy az általam "linkelt" megoldást használja, vagy bionic tag-gel tölti le a "problémázó" image-ket (na ezért fog szólni a Plex) vagy áttér 64-bites Debian Buster rendszerre. Egyébként a Plex-nek nem a titkosítással volt a baja, odáig el sem jutott
![;]](//cdn.rios.hu/dl/s/v1.gif)
! -
tama777
tag
Nemrég újraraktam a linuxserver/nextcloud konténert (Raspberry Pi 4 + OMV5) és volt problémám nemcsak ezzel, hanem a linuxserver/plex konténerrel is. Ha nálad is az látható a Portainer/Nextcloud log-ban, hogy nem tud létrehozni egy bizonyos "cert" fájlt, akkor ez lesz a megoldás: [link]
-
tama777
tag
válasz
tama777
#15110
üzenetére
Rosszul írtam, helyesen: a keyfile-okat érdemes UUID-vel hozzátársítani a titkosított meghajtókhoz, így esetleg adat kábel felcserélése esetén is fogja tudni a LUKS plugin, hogy melyik kulcs melyik meghajtóhoz tartozik!
#15120 Tarokk79
Ha az automatikus feloldás be van állítva, akkor minden ugyanúgy működik, mint amikor titkosítás nélkül használod a meghajtókat. Rendszer indítás elején végbemegy a feloldás.
Ha manuálisan történik a feloldás, akkor a Samba megosztás onnantól kezdve találja meg a megosztott könyvtárakat, miután feloldottad a meghajtókat. Viszont pl. Docker-ben futtatott konténer esetén ez a megoldás tud problémákat okozni.
-
tama777
tag
Van persze OneDrive/Személyes tár
. Az SD kártyán nekem csak a titkosított keyfile-ok vannak. Titkosított meghajtót jelszóval hozol létre, majd a generált keyfile-t (ebből összesen 31-et tudsz hozzáadni) a beállított jelszóval adod hozzá a meghajtóhoz. Ha elveszne az egyik keyfile-od, akkor még lehet hozzáadni másikat bőven! -
tama777
tag
válasz
Tarokk79
#15109
üzenetére
Ennyire nem merültem bele a titkosítás rejtelmeibe, nálam 3 HDD van titkosítva (nincsenek raid-ben), melyeket az OMV indulásakor a külső sd kártyán lévő titkosított kulcsokkal automatikusan felold (ha nincs bedugva az sd kártya, akkor ugye nem tudja). A külső HDDnél is megoldható a titkosítás automatikus feloldása, ha az OMV indításakor már alapból hozzá van csatlakoztatva a géphez (egyébként közben is, csak akkor manuálisan tudod jelszó vagy kulcs használatával), viszont mindenképpen ajánlott UUID-vel megoldani és nem cimkével a csatolást (ha naprakész OMV-t használsz, akkor az újonnan csatolt meghajtóknál már nincs is cimkés csatolás), így biztos nem kavarodnak össze a HDD-k feloldáskor. Más gépre rakva is működik, természetesen a LUKS plugin legyen telepítve.
Rendszer meghajtót nem éreztem fontosnak, hogy titkosítsam, így ezzel nem foglalkoztam.
Rsync-et nem használok, hogy az föl tudja-e oldani magától a távoli titkosított meghajtót passz, esetleg valaki más meg tudja mondani.
-
tama777
tag
válasz
wd.taz
#14443
üzenetére
Feltettem az SSD-hez szükséges "izét", azzal kell még valamit csinálni?
Ha végigcsináltad 1-9-ig a lépéseket (a 8. lépés elvileg GPT rendszer partíció esetén kell), akkor nem kell mást. (SSD használatakor még beillesztheted a noatime,nodiratime után a discard csatolási opciót is: noatime,nodiratime,discard,errors=remount-ro)A HDD-k töredezettségmentesítésére van mód? Hogyan?
Ezzel a kérdéssel még nem foglalkoztam, majd valaki szaki megmondja vagy másik linuxos topikban kérdezd meg.
Az egyik HDD-re azt írja, hogy vannak rajta badsector-ok?
Új mindkettő, én ollóztam ki a zacskóból. Ez valami anomália, vagy a PCIE-> SATA kártya okozhatja? Az egyik HDD ezen van...., vagy rossz lenne a HDD?
Ez meg egy olyan kérdés, hogy bármi is lehet! Nekem még nem volt olyan HDD-m, ami újkorában badsector-os lett volna, de hallottam már olyanról, hogy másnak igen. Mi okozhatja? Lehet a kártya (ez nem derült ki: azon van a rossz HDD?), de okozhatja más is (tápegység, sata kábel, belerúgsz a gépbe, leejted, áramszünet, stb. (bár ezekről is csak olvastam vagy hallottam)). Ha új a HDD, akkor próbáld meg garanciában cseréltetni vagy állj el a vásárlástól, ha még megteheted! De előtte azért én leellenőrizném máshogy is: leállítod a NAS-od, áramtalanítás után kiveszed az ellenőrizni kívánt lemezt (ha nem UUID-vel vannak fölcsatolva a lemezeid, akkor érdemes megjegyezni, hogy melyik lemezt melyik SATA kábelről húztad le), utána pl. külső házzal/usb-sata kábellel windowsos gépre rádugod és ellenőrzöd őket pl. ezzel -
tama777
tag
Elvileg nem fordulhat elő, én még részemről nem találkoztam ilyennel, még nem veszett el soha az adminom joga, de nem zárnám ki, hogy nincs ilyen. Ha mégis előfordulna ilyen, akkor le tudod ellenőrizni, hogy meg van-e az adminodnak a joga, illetve vissza is tudod állitani, ha nincs: link
-
tama777
tag
válasz
Vektor77
#14368
üzenetére
Nálam NVMe SSD-n van a rendszer (OMV5 5.3.9 image UEFI módban telepítve, az 5.5.11es image-t még nem "kellett” használnom). A telepítést az Összefoglaló alapján csinálom mindig (ugye annyi a különbség OMV5 esetén SSH-n frissítve a rendszert a frissítés végén omv-confdbadm populate parancsot kell kiadni), tehát a GUI-ra már csak akkor lépek, amikor a rendszer és az OMV Extra is fel van telepítve és frissítve SSH-n keresztül.
Az NVMe SSD-vel két problémám volt csak, az egyik hogy a BIOS-ban a FAST boot-ot át kellett állítanom Normal boot-ra máskülönben 10-ből 9szer nem talált boot eszközt a gép (ez gondolom alaplapi "hiba", mintsem OMV), a másik problémám a flasmemory plugin-nal adódott, mert ha megcsináltam lépésről lépésre (7.,8.,9. lépés is megvolt), akkor induláskor mindig kereste a swap partíciót az OMV és így sokára töltött be a rendszer.
(Illetve akadt egy 3. is, bár ez nem "hiba", mégpedig a smartmontools plugin. Ebből fel kellett tennem a smartmontools_7.1-1_amd64.deb csomagot, mert az alap nem ismerte fel.)
-
tama777
tag
-
tama777
tag
válasz
meridaharcos
#13091
üzenetére
Igen, most már csak futtasd az
echo 'ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0578", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' >>/etc/udev/rules.d/10-uas-discard.rules
parancsot és indítsd újra a rendszered (akár többször is) és ellenőrizd az lsblk --discard paranccsal a meghajtódat. -
tama777
tag
válasz
meridaharcos
#13088
üzenetére
Szerintem a
Bus 002 Device 004: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
lesz a nyerő, (ezek szerint ugyanaz a vezérlője a Te külső házadnak, mint az enyémnek), de biztosra ez megmondja:
cat /sys/block/sda/../../../../../../idVendorcat /sys/block/sda/../../../../../../idProduct -
tama777
tag
válasz
meridaharcos
#13081
üzenetére
Elvileg igen, nálam így megoldódott:
Adott egy RPi3 + Kingston SSD/Delock USB ház + OMV5.
Ha futtatom az lsblk --discard parancsot hasonlóan a Tiédhez az /sda meghajtó nem támogatja a TRIM-et:root@omvRPi:~#
lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 0B 0B 0
└─sda1 0 0B 0B 0
mmcblk0 0 4M 584M 0
├─mmcblk0p1 0 4M 584M 0
└─mmcblk0p2 0 4M 584M 0Ha a provisioning_mode fájlban a full bejegyzést kicserélem unmap-ra, akkor a kernelt "megkérem", hogy használja a TRIM-et az USB-s SSD-én:
root@omvRPi:~#
echo "unmap" >/sys/block/sda/device/scsi_disk/*/provisioning_modeÍgy már ez szerepel a fájlban:
root@omvRPi:~#cat /sys/block/sda/device/scsi_disk/*/provisioning_mode
unmapIsmét futtatva az lsblk --discard parancsot már az látszik, hogy a TRIM támogatottá vált a külső SSD-n (amíg újra nem indítom az OMV-t):
root@omvRPi:~#lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 4G 0
└─sda1 0 512B 4G 0
mmcblk0 0 4M 584M 0
├─mmcblk0p1 0 4M 584M 0
└─mmcblk0p2 0 4M 584M 0Ahhoz, hogy véglegesítsük a TRIM-et a meghajtón tudni kell a külső ház azonosítóit:
root@omvRPi:~#
lsusb
Bus 001 Device 006: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Nálam az idVendor = 152d, az idProduct = 0578, amit a következő parancsba behelyettesítve és futtatva újraindítás után is aktiválódik a TRIM a külső meghajtón:
root@omvRPi:~#echo 'ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0578", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' >>/etc/udev/rules.d/10-uas-discard.rules
TRIM ellenőrzése: az első módszerrel teszteltem a provisioning_mode fájl módosítása előtt és után is. A módosítás előtt a teszt fájl törlése után ugyan azokat az értékeket kaptam vissza a hdparm --read-sector parancs futása után, mint törlése előtt, tehát a TRIM funkció nem működött. Viszont a provisioning_mode fájl módosítása után már csupa 0-át kaptam, tehát működik a TRIM funkció!Remélem Nálad is működni fog!
-
tama777
tag
válasz
meridaharcos
#13078
üzenetére
Szia,
Igen ez azt mutatja, hogy az SSD támogatja-e a TRIM-et!
-
tama777
tag
válasz
lovi27
#13076
üzenetére
Eddig engem sem foglalkoztatott a téma, amit tegnap bemásoltam
lsblk –discardkimenet is azt mutatta, hogy a TRIM támogatva van az SSD-én (ez egy asztali gép, SATA porton van csatlakoztatva az SSD), de ma megnéztem az RPi3-ra dugott usb-s külső házas SSD-vel mi a helyzet és ugyan azt kaptam vissza eredményül, mint (#13072) meridaharcos. Úgyhogy, ha az SSD és a külső usb-s ház is támogatja a TRIM-et, akkor be lehet állítani, hogy működjön is. -
tama777
tag
válasz
meridaharcos
#13072
üzenetére
Le kellene kérni a hdparm -I /dev/sda paranccsal, hogy az SSD támogatja-e a TRIM-et:
hdparm -I /dev/sda
* Data Set Management TRIM supported (limit 8 blocks)Telepítsd az sg3-utils-t:
apt install sg3-utilsFuttasd a következő két parancsot:
sg_readcap -l /dev/sdaRead Capacity results:
Protection: prot_en=0, p_type=0, p_i_exponent=0
Logical block provisioning: lbpme=0, lbprz=0
Last LBA=937703087 (0x37e436af), Number of logical blocks=937703088
Logical block length=512 bytes
Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
Lowest aligned LBA=0
Hence:
Device size: 480103981056 bytes, 457862.8 MiB, 480.10 GBLogical block provisioning: lbpme=? mennyi az értéke?
sg_vpd -a /dev/sdaLogical block provisioning VPD page (SBC):
Unmap command supported (LBPU): 1
Write same (16) with unmap bit supported (LBPWS): 0
Write same (10) with unmap bit supported (LBPWS10): 0
Logical block provisioning read zeros (LBPRZ): 0Unmap command supported (LBPU): ? mennyi az értéke?
Nézd meg mi a tartalma provisioning_mode fájlnak:
cat /sys/block/sda/device/scsi_disk/*/provisioning_modefull
Ha ezek megvannak, akkor megyünk tovább....
-
tama777
tag
válasz
meridaharcos
#13072
üzenetére
Nem kizáró ok, amit linkeltem forrás is azt írja, hogy van olyan eset, amikor hiába támogatott a TRIM külső házas SSD-k esetén, a kernel nem ismeri fel automatikusan ezt a képességet. Van egy RPi3am külső SSD-vel, du. vagy holnap megnézem.
-
tama777
tag
válasz
meridaharcos
#13069
üzenetére
Ne haragudj, de amit az előző válaszomban írtam az csak ellenőrzi, hogy a meghajtód támogatja-e a TRIM funkciót! Elnézést!
-
tama777
tag
válasz
meridaharcos
#13069
üzenetére
Futtasd az
lsblk --discardparancsot, ha a DISC-GRAN és a DISC-MAX oszlopaiban lévő értékek nem nullák az adott meghajtónál, akkor támogatva van a TRIM.Nálam így néz ki (sda – SSD, sdb – HDD) :
root@OMV:~# lsblk --discardNAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZEROsda 0 512B 2G 0├─sda1 0 512B 2G 0├─sda2 0 512B 2G 0├─sda3 0 512B 2G 0└─sda4 0 512B 2G 0sdb 0 0B 0B 0└─WD1TB 0 0B 0B 0 -
tama777
tag
válasz
meridaharcos
#12726
üzenetére
Egy konténert nem csak docker-compose.yml fájllal lehet csak létrehozni. Amit bemásoltam példát megfelelő paraméterekkel csak futtatni kell parancssorból (pl. Puttyból rootként), ha lefutott ott lesz a Portainer-ben a konténerek között, csak el kell indítani. De készíthetsz kézileg is konténert a Portainerben, mint régen OMV4 alatt a pluginban.
-
tama777
tag
válasz
meridaharcos
#12721
üzenetére
Nem használok, viszont próbáld ki a jlesage/jdownloader-2-t, teljesen Portainer kompatibilis (A jlesage/mkvtoolnix-t használom illetve a jlesage/handbrake módosított változatát, ezek jól működnek.).
Példa:
docker create \
--name=JDownloader \
-e USER_ID=1000 \
-e GROUP_ID=100 \
-e TZ=Europe/Budapest \
-e DISPLAY_WIDTH=1680 \
-e DISPLAY_HEIGHT=1050 \
-p 5802:5800 \
-p 5902:5900 \
-v /srv/dev-disk-by-label-OMV5AppData/AppData/JDownloader:/config \
-v /srv/dev-disk-by-label-WD6TB/Downloads:/output \
--restart unless-stopped \
jlesage/jdownloader-2 -
tama777
tag
válasz
stigma
#12655
üzenetére
Van egy felhasználóm pl. Bela, ha lekérem az "id"-t (id Bela), akkor UID=1000 tehát Dockerben a PUID=1000, GID=100 tehát Dockerben a PGID=100 + Bela-nak be van állítva ACL-ben, hogy tudja írni/olvasni (példámban lévő) az AppData, Downloads illetve Watch mappákat, (nálam Bela a tulajdonosa is ezeknek a mappáknak). A port számok (45678/tcp ill. 45678/udp) pedig be vannak a Router-ben állítva a NAS ip címéhez. Mondjuk én OpenVPN-as-t használok a távoli eléréshez (így nálam csak a 1194/udp, illetve a példában szereplő 45678/tcp és a 45678/udp port van nyitva). A config/settings.json-ban még nem kellett állítanom semmit, mentette az UI-n megadott paramétereket.
Nálam így néz ki és működik is:
docker create \
--name=Transmission \
-e PUID=1000 \
-e PGID=100 \
-e TZ=Europe/Budapest \
-e TRANSMISSION_WEB_HOME=/transmission-web-control/ \
-e USER=amilyennevetakarsz \
-e PASS=amilyenjelszótakarsz \
-p 9091:9091 \
-p 45678:45678 \
-p 45678:45678/udp \
-v /srv/dev-disk-by-label-OMV5AppData/AppData/Transmission:/config \
-v /srv/dev-disk-by-label-WD1TB/Downloads:/downloads \
-v /srv/dev-disk-by-label-WD1TB/Watch:/watch \
--restart unless-stopped \
linuxserver/transmission -
tama777
tag
válasz
Pelican
#12420
üzenetére
Szerintem sincs baj az OMV alatt az USB-s HDD felcsatolással, nekem is működik. Amire én válaszoltam az nem a logikai hibára szólt, hanem arról, hogy nem tudja a megosztott mappák között kiválasztani az USB-s meghajtót! Ha megnézed TCr fórumtárs linkelt "fstab"-os képét láthatod, hogy az USB-s HDD nincs fölcsatolva az OMV alá, bár látszik a fájlrendszerben, hogy föl van csatolva, de nem az OMV csatolta föl magának. Ha Ő mindenképp UUID-vel akarja használni a külső HDD-t, akkor használja a "noauto" opciót. Ez most trükkös vagy nem, az már ott eldőlt szerintem, hogy "UUID"-t használ.
Megcsináltam addig, amíg TCr ft. csinálta:
"fstab"-ban hozzáadtam a saját USB-s HDD-m UUID-jét, ahogy neki javasolták, elmentettem, újraindítottam:
Meg is jelent "fölcsatolva" az OMV/Fájlrendszerek menüpont alatt:
A Megosztott mappáknál viszont nem tudtam kiválasztani a meghajtót, ahogy Ő sem:
Ezután "fstab"-ban hozzáadtam a "noauto" opciót, mentettem és újraindítottam:
Ismét megjelent a OMV/Fájlrendszerek menüpont alatt, de már nem fölcsatolva:
Fölcsatoltam és már lehet is választania a Megosztott mappáknál a meghajtót:
Az "fstab"-ban pedig, ha megnézed már az OMV csatolta föl magának a meghajtót:
3 újraindítás illetve 1 leállítás+indítás után is működik!
-
tama777
tag
LUKSEncryption-t használok, aminél hasonlóan kellett megoldanom a meghajtók automatikus felcsatolásait, szerintem ennél is működne.
Az /etc/fstab-ban, ahol most van azUUID=83410ba7-4d78-4cbe-a458-b93327386f6d /mnt/WD4TB ext4 defaults 0 0tedd be a „noauto” opciót, szerintem így nézzen ki:
UUID=83410ba7-4d78-4cbe-a458-b93327386f6d /mnt/WD4TB ext4 defaults,noauto 0 2Ezután mentés + restart, majd az OMV-n belül a fájlrendszereknél csatoltasd föl az OMV-vel a meghajtót, magyarul az OMV intézze a csatolást magának.
-
-
tama777
tag
válasz
magmakocka
#12162
üzenetére
Nálam rendben működik a WiFi konfigurálás. Telepíteni vezetékesen szoktam, majd GUI-n állítom be a WiFit.
-
tama777
tag
válasz
Grawens
#12124
üzenetére
Eddig nálam frissítésről frissítésre megmaradt az FTP hiba, érdekes (nem zavar, nem használom, de mindig leellenőrzöm, esetleg megjavult-e). Az itthoni gépen nekem is friss telepítés van, ugyan úgy hibával elszáll az FTP. De legalább most már nem érzem magam kakukktojásnak
! -
tama777
tag
válasz
szpeti40
#12077
üzenetére
Igazán nincs mit, lényeg, hogy az új helyen lévő config mappád jogosultsága egyezzen meg az elődével, illetve a biztonság kedvéért az eredeti config mappát addig ne töröld, amíg nem működik minden rendesen! (Én pl. hetente készítek róla biztonsági mentést, mivel a rendszer SSD-m ketté van osztva és a Docker config mappám van a 2. partíción. Már volt, hogy behalt az OMV-m (saját hibámból) és újra kellett raknom, ilyenkor csak visszamásolom a config mappát, létrehozom a konténereket, és működik újra minden, mintha semmi sem történt volna!)
-
tama777
tag
válasz
tama777
#12075
üzenetére
Pontatlanul írtam az első lehetőséget, elnézést!
1. Ha a Docker konténerek létrehozásakor a "/sharedfolders/DockerConf"-os útvonalat használtad, akkor elég a Megosztott mappáknál átállítani a "DockerConf" mappád meghajtóját (próbálva, semmit nem állítottam, csak a meghajtót módosítottam és rendben működik a dolog). Ezután újraindítod a Docker-t vagy a géped és az új helyen lévő könyvtáradból dolgoznak a Docker konténerek.
-
tama777
tag
válasz
szpeti40
#12070
üzenetére
Nem hinném, hogy magától átköltözne, szerintem csak minden konténert újra kreálna az alap beállításokkal.
Ha azt szeretnéd, hogy minden ugyanúgy menjen, mint eddig (pl. Plex ne kezdjen újra adatbázist készíteni, Torrentjeidet ne kelljen újra hozzáadogatni), akkor csatold fel az ssd-t, másold át a komplett "DockerConf" mappádat az SSD-re (a jogosultságokat ellenőrizd, hogy a Docker-ben használt felhasználód tudja írni-olvasni).Innen 2 választásod lesz:
1. Ha a Docker konténerek létrehozásakor a "/sahredfolders/DockerConf"-os útvonalat használtad, akkor elég a Megosztott mappáknál átállítani a "DockerConf" mappád elérési útvonalát (próbálva, semmit nem állítottam, csak az útvonalat módosítottam és rendben működik a dolog). Ezután újraindítod a Docker-t vagy a géped és az új helyen lévő könyvtáradból dolgoznak a Docker konténerek.2. Ha a Docker konténerek létrehozásakor az "/srv/dev-disk-by-label-XXXXX/DockerConf" útvonalat használtad, akkor minden konténerednél újra be kell állítanod az új elérési útvonalat.(pl.: Portainer-ben: Duplicate/Edit)
-
tama777
tag
válasz
Tav-Csoves
#11968
üzenetére
Docker-ben meg tudod csinálni, hogy a ruTorrent image-hez két konténert készítesz csak más néven (meg más port számokat állítasz be a host-on nekik + külön /config mappák), az egyiket a 4TB-os lemezhez állítod be, a másikat pedig az 1TB-oshoz.
-
tama777
tag
válasz
lovi27
#11964
üzenetére
Köszönöm a részletes válaszod!
Kb. 2 éve, amikor elkezdtem OMV-t használni előtte 2-szer olvastam át a fórumot nagyjából 9000 hozzászólásig (én is csak olvastam és tanultam belőle), mindent megtaláltam köztük (amikor problémám akadt), ami kellett nekem, hogy egy működő saját igényeimet kielégítő házi szervert üzemeljek be. A Docker-rel viszont annyi minden jött az OMV-hez (azt tudom, hogy sok mindent eddig is fel lehetett tenni natívan OMV/Debian alá), hogy az már csak egyén kérdése, mit és mire szeretne még Docker-ben használni az illető, még ha az nem is OMV "specifikus".
-
tama777
tag
válasz
lovi27
#11965
üzenetére
Én kényelmi szempontból használom, talán olyan nekem, mint a filmeknél a Plex. Letölti az album borítót, ha hiányzik, létrehozhatok playlist-eket, ha egy előadótól szeretnék csak zenéket hallgatni, akkor beírom a nevét a keresőbe és listázza az összes zeneszámát. Az, hogy távolról VPN-en érem el vagy nyitok neki portot és használom, mint egy zene szervert, az meg egyéni döntés (a VPN-ben én jobban megbízok). A fájlokat én is szelektálva tárolom a szerveren, sőt a DLNA-t is használom helyi hálón, mert az utólag ”felokosított” házimozi + hifi nem kezeli a zene szervert, de a DLNA-t igen.
-
tama777
tag
válasz
lovi27
#11958
üzenetére
És tényleg, lebuktam
elfelejtettem kivenni az "m."-t a linkből!Az "off"-olást pedig azért használom a hozzászólásaimban szerintem, mert amiket így írok azok vagy nem tartoznak közvetlenül az Openmediavault-hoz, vagy lehet más megoldás is arra amit kérdeztek, mint amit én írtam illetve használok.
Ha már off, a következőt szeretném megkérdezni: Gondolom a Docker beüzemelése és a használata már egész szerves részét képezi az OMV-nek, viszont amiket használunk benne azokkal mi a helyzet? Azok ide tartoznak? Lehet róluk itt a fórumon belül írni, kérdezni (most nem olyanokra gondolok, mint a Plex, Transmission, OpenVPN stb., amik OMV5 előtt plugin-ként is elérhetőek voltak)? Vagy azok már más topikba tartoznak? Ha valaki kérdezi, hogy kell egy konténer-t elkészíteni, beállítani az mehet ide vagy inkább privátban? -
tama777
tag
válasz
thomcat
#11953
üzenetére
Szia! Én Docker-ben használom az Airsonic-ot, ezzel hallgatok zenét androidos telón (Windows-on MusicBee-hez és foobar2000-hez is van subsonic plugin). Nekem bevált.
Mondjuk én nem engedem ki a routeren, ha mégis szeretnék zenét hallgatni távolról, akkor csatlakozok OpenVPN-nel az OMV-s hálózathoz és elérem az Airsonic-ot, mintha helyi hálón lennék!
-
tama777
tag
válasz
lovi27
#11891
üzenetére
Ez így rendben van, teljesen egyetértek Veled! Érteni kell, mit hova miért írok. De, amikor elkezdtem OMV-t használni (én még új vagyok, kb. 2 éve, már a stabil OMV4-gyel) még nem nagyon volt szó Docker-ről itt a fórumon, ezért valahol el kellett kezdeni megismerkedni vele (szerintem alapnak jók voltak a videók, feltéve ha megértetted, hogy itt nem mindig jön be a copy-paste). Ma már én sem nézek videókat, kinézek valamit a Docker Hub-on és állítom be magamnak (ha esetleg nem "OMV" specifikus a dolog, akkor irány a Github vagy a saját oldala, ahol lesz hozzá dokumentáció)! Viszont mai napig van olyan konténerem, amit Portainer-ben nem tudok beállítani csak parancssorból.
Szerintem az 5.3.4-est azért is tették elérhetővé, hogy ez a /sharedfolders-es módosítás alapból benne legyen!
-
tama777
tag
válasz
lovi27
#11880
üzenetére
Reggel volt időm, felraktam egy szabad meghajtóra az itthoni gépen az 5.3.4-es standalone telepítőt. Az FTP tényleg elindul 2x Alkalmazás gombbal, viszont újraindítás után piros pötty van a "Jelenleg fut"-nál. Megosztottam egy mappát az FTP-nél, ismét kétszer kellett alkalmazni az Alkalmazás gombot, működött is, amíg újra nem indítottam
.Azt értettem, hogy mi lesz a /sharedfolders-es mappa sorsa + le is van írva, ha valaki szeretné használni vissza tudja állítani, de ahogy ott a fórumon is az egyik tag írta nagyon sok olyan beállítási útmutató van a neten (mondjuk az újak már srv könyvtár használatával készülnek), ahol a /sharedfolders/.... elérési utat használják (javában a Docker-nél). Tehát, ha valaki telepíti most az 5.3.4-es OMV verziót és tegyük föl be akar állítani Docker-ben egy év eleji videó alapján egy konténert, nem biztos, hogy fogja egyből érteni most miért nem működik a dolog (lehet csak én reagálom túl a dolgot?).
-
tama777
tag
válasz
fonok87
#11867
üzenetére
Te hol láttad, hogy stabil az 5.3.4-es verzió? Én tegnap frissítettem 5.3.3-ról, de még mindig "unstable" volt a Frissítéskezelőben.
Más: Az 5.3.3-as verziónál láttam egy olyat, hogy megszüntetik a sharedfolders-es opciót (pl. Dockerben könvyvtár útvonal megadása), mert problémás volt (nekem frissítés után nem változott semmi).
Lehet, hogy ha frissen telepíteném az 5.3.4-est, abban már alapból tiltva lenne (mondjuk azt írták, hogy vissza lehet állítani, ha valaki akarja) ? -
tama777
tag
válasz
kaczati
#11847
üzenetére
Nem kell, ez akkor is fog futni, csak akkor áll le, ha Te leállítod! (Ha mégsem így lenne, akkor a "run" helyett használd a "create" -t, ilyenkor csak létrehozza a konténert, majd indítsd el manuálisan és futni fog NAS újraindítás után is, amíg le nem állítod!)
Illetve az "unless-stopped" helyett használhatod az "always"-t is! -
tama777
tag
válasz
kaczati
#11845
üzenetére
Igen arra az id-re gondoltam, akkor az jól van beállítva!
Ha parancssorból futtatod, akkor valahogy így nézzen ki:docker run \
--name=MKVToolnix \
-e USER_ID=1000 \
-e GROUP_ID=100 \
-e TZ=Europe/Budapest \
-p 5800:5800 \
-p 5900:5900 \
-v /sharedfolders/MKVToolnix:/config \
-v /sharedfolders/Storage:/storage \
--restart unless-stopped \
jlesage/mkvtoolnixA "-d" csak akkor kell, ha háttérben akarod futtatni a konténert.
A "-v" résznél a ":" bal oldalán a saját megosztott mappáid kellenek! Nekem a megosztott mappáim között van egy MKVToolnix mappa és egy Storage mappa, de Te azt írd oda, ami Neked van!!! -
-
tama777
tag
válasz
kaczati
#11840
üzenetére
Igen, amik bal oldalon vannak azokat jobb oldalra kell tenni (ha oda kattintassz ki tudod választani ), bal oldalon meg ki kell választani azokat a mappákat a rendszereden, amiket beállítassz a /config-nak meg a /storage-nak!
Illetve a zöld csúszkákat állítsd át, mert így csak olvasni tudja a beállított mappáidat! -
tama777
tag
válasz
kaczati
#11835
üzenetére
Az Exposed Port-nál nyomj a lefelé nyílra és a legördülő menüből válaszd az 5800-at, mellette a Host Port-hoz pedig írd be 5800 (vagy egy olyan szabad port számot amit Te szeretnél) ezután kattints a "+" - ra. Ha esetleg el akarod érni VNC-vel is, akkor az új sorban válaszd az Exposed Port-nál az 5900-at és állítsd be az 5900-at (vagy amit szeretnél) a Host Port-nál és ismét a "+"-ra kattints! Ha a többi beállításod rendben van mentés és indítható a konténert!
-
tama777
tag
válasz
akipapi
#11768
üzenetére
Már találkoztam ilyennel. Amikor elindítod a frissítést lesz két választási lehetőség (linuxserver/nextcloud + linuxserver/mariadb esetén tuti) a frissítés befejezésére: parancssorból vagy webes felületen. Ha a parancssorit választottam nekem is karbantartási módba kötött ki (nem kerestem megoldást), ha a webes befejezést, akkor sikerült a frissítés (már egy párszor frissítettem így, hiba nélkül)!
ui.: a linuxserver csapata nem ajánlja és nem is támogatja a konténeren belüli frissítést (Plex, Nextcloud).
-
tama777
tag
válasz
szpeti40
#11751
üzenetére
Hát nem tudom mi lehet a hiba (azt írtad nyílt tracker-rel megy, akkor nem lehet, hogy a zárt tracker beállításával van a hiba és nem a konténerrel?)! Hátha jelentkezik valaki aki, használ Jackett-et zárt tracker-rel. Elvileg tud, de még nem kellett használnom.
-
-
tama777
tag
válasz
szpeti40
#11739
üzenetére
Jackett-et nem használok, bár nem gondolnám, ha minden jól volt beállítva a konténer létrehozásakor, hogy a Watchtower miatt nem működik a dolog.
Watchtower-es frissítgetéssel nekem akkor volt gondom, ha nem adtam meg a konténer létrehozásakor minden olyan könyvtárat, amit kér a konténer (vagy elírtam a konténer könyvtárát (pl. /config helyett /confi-t írtam, ilyenkor a /config könyvtárához csatol egy random könyvtárat)).
Konkrét példa: Létrehoztam a Grafana konténert, beállítottam, amit a telepítési dokumentum írt (port szám, név stb.). Elindítottam, működött, beállítottam már egy csomó grafikont. Aztán egy Watchtower-es frissítés után minden beállítás, grafikon odalett
. Kiderült, hogy a Grafana létrehoz egy saját könyvtárat (Portainer/Volumes résznél látható), amibe a konfig fájlt tárolja. Amikor a Watchtower frissít az új konténer más random könyvtárat hoz létre, amibe az alap konfig fájl kerül és így nem találja meg a régit. Magyarul adnom kellett meg nekem egy saját könyvtár útvonalat, ahol már minden frissítés után meglesz a konfig fájl! -
tama777
tag
válasz
szpeti40
#11728
üzenetére
OpenVPN-as-t Dockerben próbáltad már (OMV5-re nincs OpenVPN plugin)? Én azzal érem el a távoli OMV-s gépet (Airsonic-ot, Portainer-t, Glances-t stb.), illetve az azon a hálózaton lévő PC-t, router-t, stb.. TDL videója alapján simán működik, viszont annyi kiegészítéssel (a videó alapján csak csatlakozni tudtam a hálózathoz, az OMV-be belépni már nem), hogy a Configuration/VPN Settings oldalon a Routing mezőbe, (ahol a 172.17.0.0/16 van) add hozzá azt a hálózatot amihez csatlakozni kívánsz (pl. 192.168.1.0/24 ekkor az egész hálózatot látod vagy megadhatsz csak egyes címeket is pl. 192.168.1.23 192.168.1.102 stb.)
Valahogy így nézzen ki:172.17.0.0/16
192.168.1.0/24.Már egy párszor frissítette a Watchtower, mióta használom, de még sosem volt gubanc vele!
-
tama777
tag
válasz
lovi27
#11730
üzenetére
Én is köszönöm a visszajelzést. Egyébként az alap rendszerben más hibával nem nagyon találkoztam (azért volt, hogy a bekapcsolt "Monitorozás" funkció miatt 2 percet is várni kellett, hogy a szolgáltatások elinduljanak, de ezt egy frissítés megoldotta). Majdcsak összeáll!
-
tama777
tag
válasz
lovi27
#11724
üzenetére
Igazán nincs mit! A lényeg, hogy működik! Hát nem tudom meddig marad az OMV5 béta állapotban, Neked pl. működik az FTP? OMV4 alatt működött, de OMV5 alatt nem megy (se az itthoni gépen, se a távolin, se VirtualBox-on). Ha törlöm a /run/proftpd.pid fájlt, akkor elindul, de újraindítás után megint nem megy. Mondjuk én nem használom, de ez mai napig nálam egy hiba az OMV5ben.
Egyébként a DNS-t nekem sem kellett állítanom OMV4 alatt sosem, viszont amikor megjelent az OMV5, felraktam VirtualBox-ban, a telepítés megvolt, de nem tudtam semmit sem telepíteni se frissíteni. Utána olvasva ezt találtam (Do not leave DNS setting empty; it is essential for fetching updates. A common value is to use the same IP address as the gateway. If unsure, just use google DNS
8.8.8.8.), ezt beállítva egyből működött minden. Azóta mindig beállítom a DNS szerver részt, ha működne nélküle, akkor is. -
tama777
tag
válasz
#49155328
#11717
üzenetére
Előtte ugye végzi az ipv4dhcp konfigurálást, na amikor azzal végzett és amint megjelenik az ipv6dhcp érzékelés rész nagyon, de nagyon gyorsan nyomj egy mégsét (space), ezzel kihagyja az ipv6dhcp konfigurálását és megy tovább a telepítés. Ha nem vagy gyors és újra bejön a szimpla kék képernyő, nyomj egy Ctrl+C-t, válaszd a Hálózat beállítás részt és futhatsz neki újra.
Lényeg, hogy siker van!
-
tama777
tag
válasz
lovi27
#11699
üzenetére
Megnéztem, nekem működik rendben.
Ami eszembe jutott, hogy VirtualBoxban addig nem tudtam frissítéseket telepíteni, amíg a Hálózat/Interfészeknél a hálózati adapternek nem adtam meg a Google DNS szerverét (bár én már az OMV Extrákat sem tudtam telepíteni), illetve ha a Dockernek más telepítési útvonalat állítottam be (elvileg a sharedfolders-es útvonalat nem szereti). -
-
tama777
tag
-
-
tama777
tag
válasz
Oldman2
#11688
üzenetére
Ha megjelenik egy vagy több frissítés, akkor a Frissítéskezelőben egy frissítést kijelölsz, aktívvá válik a "Változások megtekintése" gomb (a Telepítés gomb mellett), kattints rá és láthatod, hogy milyen változások történtek az adott csomagnál. Ez OMV5nél így van, a régebbieknél már nem emlékszem, hogy volt-e ilyen.
-
tama777
tag
válasz
Nagymelák
#11678
üzenetére
Amit megadsz könyvtárat, ahova a kész fájlokat átmásolja pl. /srv/dev-disk-by-label-Toshiba3Tb/Torrent1/Filmek/ van jogosultsága a Docker felhasználónak írni+olvasni, mert ha nincs akkor a konténer létrehoz egy sajátot és abba teszi a letöltött fájlokat. Ezt tudod ellenőrizni pl. Portainer-ben a Volumes résznél, hogy hozott-e létre a qbittorrent konténer sajátot.
-
tama777
tag
válasz
Larten
#11675
üzenetére
A Library kezelése szerintem rendben van a Jellyfin-nek (jól legyenek a könyvtárak kiválasztva ugye külön a filmek, külön a sorozatok stb.), az emlékezés és hogy hol jártam részt hétfőn megnézem, ha szükséges, mert arra nem emlékszem, hogy ezek működnek-e úgy, mint pl. a Plexben. Viszont a szerver beállításánál nézz át mindent, mert pl. ha bejelölőd, hogy hozzon létre nfo-kat, akkor azokat beteszi a filmek, sorozatok stb. könyvtárakban (bár ez engem nem zavar)! Ja és tud magyarul. Szerintem megér egy próbát max. először ne az egész filmes mappát osztd meg vele, csak egyet-kettőt.
-
tama777
tag
válasz
Larten
#11661
üzenetére
Pedig ajánlok egy Plexhez hasonlót! Próbáld ki a Jellyfin-t Dockerben (pl. linuxserver/jellyfin). Van hozzá Kodi plugin is, androidos app is, hasonló a tudása a Plex-éhez, nem kell előfizetni sem, elvileg net sem kell neki, csak ha pl. film, sorozat adatbázist frissít. Ja és többféle hardveres kódolást állíthatsz be, mint a Plexben (ennek ugye feltétele hogy a meglévő hardver a Dockerbe legyen „csatolva”). Szerintem jó media szerver alternatíva.
-
tama777
tag
válasz
Shade45
#11664
üzenetére
Most akkor webes felület vagy destop kliens? Webes felületen nekem is transzkódolni akar (így emlékszem, de ezt leghamarabb hétfőn tudom megnézni), de a PC destop kliensén ha azt állítom be, hogy eredeti minőségben akarom-e játszani a filmet, akkor nekem úgy megy. A transzkódolás hiba pedig Dockerben lehet attól, ha a Plex config mappája olyan fájlrendszeren van ahol be van állítva a „noexec” (Tiltja a bináris fájlok végrehajtását a fájlrendszeren.) opció.
-
tama777
tag
válasz
tama777
#11662
üzenetére
Az utolsó mondatom hibás: mármint a container létrehozásakor nem kellenek az NVIDIA-s sorok, csak akkor, ha hardveres kódolást is akarsz NVIDIA kártyával! A linuxserver csapata megoldotta, hogy lehessen használni hardveres kódolást pl. plex, jellyfin konténerekben. De, ha nem használsz hardveres kódolást, akkor is megjelenik az Environment mezőkben az NVIDIA_VISIBLE_DEVICES és a NVIDIA_DRIVER_CAPABILITIES sorok.
-
tama777
tag
válasz
Shade45
#11660
üzenetére
Igen, adj hozzá egy új sort, Name legyen VERSION, Value meg legyen public. OMV4et használsz? Nekem OMV5 van fönt itt Portainert használok, de konzolból szoktam telepíteni a konténereket (párszor újratelepítettem az OMVt mire sikerült Dockerben megoldási a hardveres kódolást NVIDIA kártyával, így gyorsabb volt, mint mindig mindent újra bepötyögni Portainerben) pl. nálam a Plex így néz ki (pár sort kitöröltem + Neked lehet más a PUID, a PGID stb.)
docker create \
--name=Plex \
--net=host \
-e PUID=1000 \
-e PGID=100 \
-e VERSION=public \
-e NVIDIA_VISIBLE_DEVICES=GPU-e85a88d8-99f0-b55f-6b51-d5a6d430488e \
-e NVIDIA_DRIVER_CAPABILITIES=compute,video,utility \
-v /sharedfolders/Movies:/Movies \
-v /sharedfolders/AppData/Plex:/config \
--restart unless-stopped \
linuxserver/plexEzt lefuttatom a konzolban, a Plex container megjelenik a containerek között, elindítom, és megy addig, amíg én le nem állítom (vagy amíg újabb bpo kernel meg nem jelenik, de ez csak akkor van, ha a Dockerben a default runtimenak NVIDIA van beállítva.)
Még annyit, ha nem használsz NVIDIA hardveres kódolást, akkor az NVIDIA-s sorok nem kellenek!
-
tama777
tag
(#11654) Shade45 Válasz akart lenni, de mobilon teljes nézetben nem vette, bocsi!
1. lehetőség: Watchtower használata. Ez folyamatosan ellenőrzi, hogy van-e frissebb az image-kből és ha talál automatikusan frissíti őket. Nálam a containrrr/watchtower van fenn és jól működik, van e-mailes értesítés is, mikor mik frissülnek.
2. lehetőség: linuxserver/plex image és PlexPass esetén a VERSION-nál ne a „docker”-t válaszd, hanem a „public”-ot. Ez minden docker indulásnál ellenőrzi, hogy van-e frissebb plexserver és ha van magától updateli.Én ezeket együtt használom, mivel van több containerem, amiket így frissítek, illetve eddig a VERSION=docker volt beállítva, de a legutolsó plexserver verziót nem adta ki a linuxserver csapata, így beállítottam a VERSION=public-ot, most a Plexből is a legfrissebb van. Ha valaki tud más lehetőségeket az majd kiegészít!
-
tama777
tag
válasz
szasza7103
#11070
üzenetére
Szia! Omv-ben a Hálózatok/Interfészek /eth0(vagy ami Neked van) üresen hagytad a DNS szerverek mezőt? Egyik oka lehet ez is, ha nem tudsz frissíteni vagy csomagokat telepíteni! Ha igen próbáld meg az alapértelmezett átjáródat (pl.192. 168.0.1) megadni vagy a pl. Google DNS szerverét(8.8.8.8)! Hátha ez segít.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
! 
. Az SD kártyán nekem csak a titkosított keyfile-ok vannak. Titkosított meghajtót jelszóval hozol létre, majd a generált keyfile-t (ebből összesen 31-et tudsz hozzáadni) a beállított jelszóval adod hozzá a meghajtóhoz. Ha elveszne az egyik keyfile-od, akkor még lehet hozzáadni másikat bőven!
, így már nálam is működik! Negyedik újraindításnál is elindult az FTP szolgáltatás és el is tudom érni (egy kis szépséghiba nálam azért van, hogy az indítás után kb. 30 másodpercig piros a pötty a "Jelenleg fut"-nál, de átvált zöldre).
elfelejtettem kivenni az "m."-t a linkből!
.
. Kiderült, hogy a Grafana létrehoz egy saját könyvtárat (Portainer/Volumes résznél látható), amibe a konfig fájlt tárolja. Amikor a Watchtower frissít az új konténer más random könyvtárat hoz létre, amibe az alap konfig fájl kerül és így nem találja meg a régit. Magyarul adnom kellett meg nekem egy saját könyvtár útvonalat, ahol már minden frissítés után meglesz a konfig fájl!
Új hozzászólás Aktív témák
tradeelek11Figyelem!
Megjelent a Debian 10-re épülő OMV 5 stabil kiadása.
Új telepítésre ez a verzió ajánlott.
- HIBÁTLAN iPhone 12 Pro Max 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3670 100% Akkumulátor
- Samsung Galaxy A52s 128GB, Kártyafüggetlen, 1 Év Garanciával
- Honor 200 Lite / 8/256GB / Kártyafüggetlen / 12HÓ Garancia
- HP 65W töltő eladó
- GYÖNYÖRŰ iPhone 15 Pro Max 256GB Black Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3067
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest