- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Kormányok / autós szimulátorok topicja
- Amlogic S905, S912 processzoros készülékek
- Vezetékes FEJhallgatók
- eGPU tapasztalatok
- Samsung LCD és LED TV-k
- E-book olvasók
- Épített vízhűtés (nem kompakt) topic
- ThinkPad (NEM IdeaPad)
- Milyen TV-t vegyek?
Hirdetés
-
Biztonsági aggályok miatt késik a Microsoft hatalmas AI-újítása
it A Microsoft úgy döntött, hogy biztonsági aggályok miatt elhalasztja a Recall AI funkciót, így azt csak szűkebb körben tesztelik egyelőre.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
Strand vagy hűvös szoba? A hardverek tudják a választ!
ph Asztali gépek, alkatrészek, perifériák és kiegészítők szeretnék elkerülni a napszúrást.
-
PROHARDVER!
Új hozzászólás Aktív témák
-
A_ScHuLcZ
addikt
válasz
tradeelek11 #12031 üzenetére
Én TDL guide-ját használtam a beállításhoz, és a végére úgy működött, ahogy kell.
Extraként még annyit csináltam, hogy a routeren beállítottam a hairpin nat-olást (loopback nat), hogy belső hálózatról is menjen a publikus címmel.
ui: ismét megy az OMV fórum.
[ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
válasz
lovi27 #12232 üzenetére
Elsőre egy km-es hiba, másodikra sikerült. Reboot után azt mutatja, hogy a szolgáltatás engedélyezve van, de jelenleg nem fut (piros pötty).
Az OMV nálam Intel alapú hardveren fut (ESXi alatt).
[ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
Sajnos kénytelen voltam nem megfelelően leállítani a rendszert, mivel semmilyen módon nem értem el a managementet, és a szolgáltatások sem működtek. A hiba feltehetően arra vezethető vissza, hogy elfogyott a memória, mert tele volt ilyen üzenetekkel a konzol, de belépni már nem tudtam, nem reagált semmire. (ESXi-n fut)
A gépet kilőttem, majd újraindítottam, az elérések azóta működnek, de még nem tökéletes a rendszer, SMB-n például semmilyen megosztás nem látszik, pedig aktív a szolgáltatás, és a megosztott mappák is ott vannak a konfigban, ahogy eddig. Logban semmilyen hibára utaló jelet nem találtam, minden diszk látszódik a /srv/ alatt, be is tudok rájuk lépni, látszódnak a fájlok, mappák, minden.
root@JBPKFILE:/srv# ls -l
összesen 44
drwxrwxrwx 26 138862 138862 4096 febr 17 2019 5f7226b4-ebc0-4e5f-9b73-febe610d194d
drwxr-xr-x 4 root root 4096 márc 6 20:37 dev-disk-by-label-datadisk
drwxr-xr-x 3 root root 4096 márc 26 22:58 dev-disk-by-label-parity
drwxrwxrwx 3 root root 4096 márc 25 17:24 dev-disk-by-label-volume1
drwxr-xr-x 4 root root 4096 ápr 20 23:59 dev-disk-by-label-volume2
drwxr-xr-x 17 root root 4096 ápr 22 12:01 dev-disk-by-label-volume3
drwxr-xr-x 9 root root 4096 ápr 20 23:59 dev-disk-by-label-volume4
drwxr-xr-x 2 ftp nogroup 4096 márc 7 02:03 ftp
drwxr-xr-x 3 root root 4096 ápr 15 16:15 pillar
drwxr-xr-x 5 root root 4096 ápr 15 16:15 salt
root@JBPKFILE:/srv#
(a volume1 hiányzik, sajnos pár hete tönkrement a diszk)Találkozott már valaki hasonló hibával?
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
válasz
lovi27 #12431 üzenetére
4GB volt neki adva az ESX-en, 2 hónapja használom így, ez az első eset. (a swap partíció mérete is 4GB, az sda5-ös az)
root@JBPKFILE:/srv# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 16G 0 disk
├─sda1 8:1 0 12G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 4G 0 part
sdb 8:16 0 16G 0 disk
└─sdb1 8:17 0 16G 0 part /srv/dev-disk-by-label-datadisk
sdc 8:32 0 5,5T 0 disk
└─sdc1 8:33 0 5,5T 0 part /srv/dev-disk-by-label-volume2
sdd 8:48 0 7,3T 0 disk
└─sdd1 8:49 0 7,3T 0 part /srv/dev-disk-by-label-volume3
sde 8:64 0 7,3T 0 disk
└─sde1 8:65 0 7,3T 0 part /srv/dev-disk-by-label-volume4
sdf 8:80 0 7,3T 0 disk
└─sdf1 8:81 0 7,3T 0 part /srv/dev-disk-by-label-parity
sr0 11:0 1 1024M 0 rom
root@JBPKFILE:/srv#A webes felületen az Access Rights Management -> Shared Folders -en belül ott van mind. Vagy úgy érted, hogy ott vannak-e a /sharedfolders/ -en belül? (omv5 óta nálam ott nincs semmi)
[ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
-
A_ScHuLcZ
addikt
válasz
lovi27 #12434 üzenetére
Igen, ott néztem, de írtam is.
(nálam angolra van állítva a webgui)
Korábbi hsz:
A webes felületen az Access Rights Management -> Shared Folders -en belül ott van mind.
Köszönöm a segítséget![ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
qBittorrentet használok, és most vettem észre egy furcsa dolgot. Több, mint valószínű, hogy kezdetek óta fennáll a jelenség, de eddig nem tűnt fel.
Szóval a probléma az, hogy a qBittorrent által letöltött fájlok/mappák jogosultságai nem állítódnak be megfelelően, alapból csak olvasási jogot kapok rá, mint OMV felhasználó. Az OMV felületén helyre lehet billenteni, ha a megosztott mappának újra beállítom és leörököltetem a jogosultságait (erre a resetperms plugin roppant hasznos), de mivel több megosztott mappába szoktam torrentezni, nem ez a legegyszerűbb és legoptimálisabb megoldás.
Valószínűleg a probléma alapvetően arra vezethető vissza, hogy én a dockerek futtatásához külön, dedikált felhasználót használok, ezen nem is szeretnék változtatni.
Ha esetleg van már olyan, aki belefutott, és tud rá megoldást, kérem ne tartsa magában!
[ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
válasz
sztanozs #12698 üzenetére
Köszönöm, kipróbáltam.
A korábban letöltött torrentekhez tartozó fájlokat és mappákat helyrerakta, de ha új letöltést indítok, az sajnos ismét rossz jogosultságokat kap. (lenti listában a mai dátummal rendelkezők)
root@OMV:/srv/dev-disk-by-label-volume3/downloads/# ls -l
összesen 32886248
-rw-r--r-- 1 dockeruser users 3724900352 máj 23 14:37 xxxxxxxxxx
-rw-rwS--- 1 dockeruser users 5045868544 máj 22 11:36 xxxxxxxxxx
-rw-rwS--- 1 dockeruser users 3527593984 máj 22 11:35 xxxxxxxxxx
-rw-rwS--- 1 dockeruser users 5135568896 máj 22 11:33 xxxxxxxxxx
-rw-rwS--- 1 dockeruser users 3595589632 máj 22 11:33 xxxxxxxxxx
-rw-rwSr-- 1 dockeruser users 2296549376 máj 22 12:04 xxxxxxxxxx
-rw-rwSr-- 1 dockeruser users 3047262208 máj 22 12:03 xxxxxxxxxx
-rw-rwSr-- 1 dockeruser users 2295234560 máj 22 12:07 xxxxxxxxxx
-rw-rwSr-- 1 dockeruser users 2842650624 máj 22 12:07 xxxxxxxxxx
-rw-rwSr-- 1 dockeruser users 2136080384 máj 22 12:03 xxxxxxxxxx
drwxr-sr-x 2 dockeruser users 4096 máj 23 14:37 xxxxxxxxxx
drwxrwsr-x 2 dockeruser users 4096 máj 22 12:06 xxxxxxxxxx
-rw-rwSr-- 1 dockeruser users 28135936 máj 22 12:04 xxxxxxxxxx
root@OMV:/srv/dev-disk-by-label-volume3/downloads/#Kiadott parancsok:
cd /srv/dev-disk-by-label-volume3/downloads/
sudo usermod -a -G users dockeruser
sudo chown -R dockeruser:users .
sudo chmod -R g+rws .[ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
Kicsit kellemetlenül jártam ma, és érdekel, hogy másnál volt-e már hasonló, esetleg menthető-e a szitu valahogyan?
Hónapok óta gond nélkül üzemelő qBittorrent containert Portainerből leállítottam, és az editnél hozzáadtam egy további elérési útvonalat a meglévő x db mellé. Utána deploy, felületre belép, és döbbenten látom, hogy az összes (200-300db) aktív torrent ment a levesbe, nincs semmi a listában. A beállítások megmaradtak, csak a futtatott torrentjeim tűntek el.
Nem értem a dolgot, hiszen a konfig mappa a containeren kívül van, és egyáltalán nem volt piszkálva.
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
válasz
A_ScHuLcZ #15372 üzenetére
Tárgytalan, container leállít, újra elindít, és most már ott van minden. Az a fura, hogy ezt egyszer már eljátszottam még a hozzászólás előtt, de akkor nem segített..
Nem szeretem az olyan hibákat, aminek nem tudom az okát (még utólag sem).
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
válasz
szasza7103 #17067 üzenetére
Szerintem nem nálad lesz a hiba, tegnap lefrissítettem a qbittorrent container-hez tartozó image-t (linuxserver/qbittorrent), és azóta pontosan ugyanezt tapasztalom. Ez nálam nem egy friss telepítés, hónapok/évek óta fut már, és a container beállításain nem változtattam.
Próbaképpen ugyanezekkel a beállításokkal visszadeployoltam a régi image-ből (14.3.8.99202110120741-7429-1bae770b2ubuntu20.04.1-ls158) egy második qbittorrent containert, és az gyönyörűen működik..
[ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
válasz
Airedhyal #17075 üzenetére
Ezt értem, de akkor kérlek segíts, hogy mi lehet a magyarázata annak, hogy a frissítés tönkre vágja, és a régit visszatéve szépen működik? Közel két éve használom, néhány frissítésen már túl vagyok, eddig mindig rendben volt utána, most viszont nem.
Továbbá elég furcsa, hogy pont akkor tapasztalok hibát, amikor újra lett építve a build:Versions
07.01.22: - Rebase to Alpine, build from source.
06.01.22: - Deprecate unstable branch.
10.02.21: - Rebase to focal.
20.01.21: - DeprecateUMASK_SET
in favor of UMASK in baseimage, see above for more information.
12.11.20: - Stop creating /config/data directory on startupTe melyik build-et használod, melyik a 4.4, a legutolsó?
[ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
Sziasztok,
Diszk cserére (bővítésre) mi a legegyszerűbb művelet?
Jelenlegi felállás:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 16G 0 disk
├─sda1 8:1 0 12G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 4G 0 part
sdb 8:16 0 16G 0 disk
└─sdb1 8:17 0 16G 0 part /srv/dev-disk-by-label-datadisk
sdc 8:32 0 5,5T 0 disk
└─sdc1 8:33 0 5,5T 0 part /srv/dev-disk-by-label-volume1
sdd 8:48 0 5,5T 0 disk
└─sdd1 8:49 0 5,5T 0 part /srv/dev-disk-by-label-volume2
sde 8:64 0 7,3T 0 disk
└─sde1 8:65 0 7,3T 0 part /srv/dev-disk-by-label-volume3
sdf 8:80 0 7,3T 0 disk
└─sdf1 8:81 0 7,3T 0 part /srv/dev-disk-by-label-volume4
sdg 8:96 0 7,3T 0 disk
└─sdg1 8:97 0 7,3T 0 part /srv/dev-disk-by-label-parity
sr0 11:0 1 1024M 0 romA két 6TB-os lemezt (sdc és sdd) szeretném cserélni 2db 8TB-osra úgy, hogy minden megosztás és hivatkozás maradjon a jelenlegiben. Megoldható, vagy túl macerás?
További nehezítő tényező, hogy SnapRAID-et használok, és az OMV ESXi alatt fut, viszont az adatdiszkek (sdc, sdd, sde, sdf, sdg) oda vannak adva teljesen az OMV-s gépnek. (disk pass-through)
Köszönöm!
[ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
válasz
szpeti40 #18281 üzenetére
Még nem néztem, néhány órával ezelőtt vetődött fel a frissítés gondolata a fejemben. Most egyébként is nagy átalakításokat csinálok, több winyót cserélek a szerverben, tehát lehet, hogy a frissítést is célszerű a napokban elvégezni. (vagy egy tiszta telepítéssel az új verziót felrakni és nulláról bekonfigurálni)
"I'd tell you a joke about UDP, but you probably wouldn't get it."
Ú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.
- Medence topik
- Külpolitika
- Formula-1
- Azonnali játékos kérdések órája
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Kormányok / autós szimulátorok topicja
- Külföldi rendelések: boltok, fizetés, postázás
- iPhone topik
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Autós topik
- További aktív témák...
- Canva Pro előfizetés - 1 éves
- Windows, Office licencek a legolcsóbban, egyenesen a Microsoft-tól - 2990 Ft-tól!
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! LEGOLCSÓBB! Automatikus 0-24
- Autómatricák a legjobb minőségben, több ezer minta! PH tagoknak 30% kedvezmény!
- Eladó Steam kulcsok kedvező áron!