Glassed Silver

Array started, I feel alive again! Here's to hoping every service gets back up flawlessly, but since it mounted without any hiccup right away after that command I'm feeling optimistic. Thank you so very much, you didn't just make my day, you made my week. Truly thank you from the bottom of my heart, @JorgeB!

Alright, sounds like a good compromise, thank you so much for willing to help on those terms. Here's a snippet of around the mount attempt. If you need more, like you suggested I'll merrily provide more. Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: Direct-Access ATA TOSHIBA MG08ACA1 0102 PQ: 0 ANSI: 6 Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: SATA: handle(0x0010), sas_addr(0x5001438024fdabe7), phy(6), device_name(0x5000039af8d2f414) Jun 20 22:43:20 Ahri kernel: sd 1:0:0:0: [sdb] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: enclosure logical id (0x5001438024fdabe0), slot(7) Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Jun 20 22:43:20 Ahri kernel: scsi 1:0:6:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) Jun 20 22:43:20 Ahri kernel: sdc: sdc1 Jun 20 22:43:20 Ahri kernel: sd 1:0:1:0: [sdc] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sdf: sdf1 Jun 20 22:43:20 Ahri kernel: sd 1:0:4:0: [sdf] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sde: sde1 Jun 20 22:43:20 Ahri kernel: sd 1:0:3:0: [sde] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sdd: sdd1 Jun 20 22:43:20 Ahri kernel: sd 1:0:2:0: [sdd] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sdg: sdg1 Jun 20 22:43:20 Ahri kernel: sd 1:0:5:0: [sdg] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: Attached scsi generic sg7 type 0 Jun 20 22:43:20 Ahri kernel: end_device-1:0:6: add: handle(0x0010), sas_addr(0x5001438024fdabe7) Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB) Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] 4096-byte physical blocks Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: Direct-Access ATA TOSHIBA MG08ACA1 0102 PQ: 0 ANSI: 6 Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: SATA: handle(0x0011), sas_addr(0x5001438024fdabe8), phy(7), device_name(0x5000039af8d2e434) Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: enclosure logical id (0x5001438024fdabe0), slot(8) Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Jun 20 22:43:20 Ahri kernel: scsi 1:0:7:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] Write Protect is off Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] Mode Sense: 7f 00 00 08 Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 22:43:20 Ahri kernel: sdh: sdh1 Jun 20 22:43:20 Ahri kernel: sd 1:0:6:0: [sdh] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: Attached scsi generic sg8 type 0 Jun 20 22:43:20 Ahri kernel: end_device-1:0:7: add: handle(0x0011), sas_addr(0x5001438024fdabe8) Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: Direct-Access ATA Samsung SSD 860 4B6Q PQ: 0 ANSI: 6 Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: SATA: handle(0x0012), sas_addr(0x5001438024fdabed), phy(12), device_name(0x5002538e90804b01) Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: enclosure logical id (0x5001438024fdabe0), slot(13) Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Jun 20 22:43:20 Ahri kernel: scsi 1:0:8:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB) Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] 4096-byte physical blocks Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: Attached scsi generic sg9 type 0 Jun 20 22:43:20 Ahri kernel: end_device-1:0:8: add: handle(0x0012), sas_addr(0x5001438024fdabed) Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] Write Protect is off Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: Direct-Access ATA Samsung SSD 860 4B6Q PQ: 0 ANSI: 6 Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: SATA: handle(0x0013), sas_addr(0x5001438024fdabee), phy(13), device_name(0x5002538e702b1ef3) Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: enclosure logical id (0x5001438024fdabe0), slot(14) Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Jun 20 22:43:20 Ahri kernel: scsi 1:0:9:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: Attached scsi generic sg10 type 0 Jun 20 22:43:20 Ahri kernel: end_device-1:0:9: add: handle(0x0013), sas_addr(0x5001438024fdabee) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: Enclosure HP Gen8 ServBP 12+2 3.30 PQ: 0 ANSI: 5 Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] Mode Sense: 7f 00 00 08 Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: set ignore_delay_remove for handle(0x0014) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: SES: handle(0x0014), sas_addr(0x5001438024fdabf9), phy(24), device_name(0x0000000000000000) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: enclosure logical id (0x5001438024fdabe0), slot(0) Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: qdepth(1), tagged(0), scsi_level(6), cmd_que(0) Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] Write Protect is off Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] Mode Sense: 7f 00 00 08 Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] Write Protect is off Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] Mode Sense: 7f 00 00 08 Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 22:43:20 Ahri kernel: scsi 1:0:10:0: Attached scsi generic sg11 type 13 Jun 20 22:43:20 Ahri kernel: end_device-1:0:10: add: handle(0x0014), sas_addr(0x5001438024fdabf9) Jun 20 22:43:20 Ahri kernel: sdj: sdj1 Jun 20 22:43:20 Ahri kernel: sdk: sdk1 Jun 20 22:43:20 Ahri kernel: sd 1:0:8:0: [sdj] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sd 1:0:9:0: [sdk] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 22:43:20 Ahri kernel: sdi: sdi1 Jun 20 22:43:20 Ahri kernel: sd 1:0:7:0: [sdi] Attached SCSI disk Jun 20 22:43:20 Ahri kernel: ata2: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: ata3: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: ata4: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: ata5: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: ata6: SATA link down (SStatus 0 SControl 300) Jun 20 22:43:20 Ahri kernel: mgag200 0000:01:00.1: vgaarb: deactivate vga console Jun 20 22:43:20 Ahri kernel: Console: switching to colour dummy device 80x25 Jun 20 22:43:20 Ahri kernel: [drm] Initialized mgag200 1.0.0 20110418 for 0000:01:00.1 on minor 0 Jun 20 22:43:20 Ahri kernel: fbcon: mgag200drmfb (fb0) is primary device Jun 20 22:43:20 Ahri kernel: mgag200 0000:01:00.1: [drm] drm_plane_enable_fb_damage_clips() not called Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid b8c88925-d8be-4ab9-8ef8-17484fdafe91 devid 1 transid 4309837 /dev/sdd1 scanned by udevd (1083) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid 878890c5-81f9-4f8f-8f69-818e2af4175e devid 1 transid 360242 /dev/sdf1 scanned by udevd (1057) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid c2923828-e4c3-483e-bc45-ba3fe7ef2b6a devid 1 transid 5985837 /dev/sdb1 scanned by udevd (1038) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid 943d58d4-9214-47a8-8d61-01272b03f9ba devid 1 transid 368310 /dev/sdg1 scanned by udevd (1083) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid 71dab375-beb9-4327-bea1-6a7ac48dcd5f devid 1 transid 133339 /dev/sde1 scanned by udevd (1038) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid 979bf416-df16-4476-91f0-ea4e6c4084b2 devid 1 transid 1796375 /dev/sdc1 scanned by udevd (1057) Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid d5b29014-e26e-4407-a52d-73db030f39ef devid 2 transid 44263972 /dev/sdk1 scanned by udevd (1057) Jun 20 22:43:20 Ahri kernel: Console: switching to colour frame buffer device 128x48 Jun 20 22:43:20 Ahri kernel: BTRFS: device fsid d5b29014-e26e-4407-a52d-73db030f39ef devid 1 transid 44263972 /dev/sdj1 scanned by udevd (1083) Jun 20 22:43:20 Ahri kernel: mgag200 0000:01:00.1: [drm] fb0: mgag200drmfb frame buffer device Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.3: removed PHC on eth3 Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.2: removed PHC on eth2 Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.1: removed PHC on eth1 Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.0: removed PHC on eth0 Jun 20 22:43:20 Ahri kernel: igb: Intel(R) Gigabit Ethernet Network Driver Jun 20 22:43:20 Ahri kernel: igb: Copyright (c) 2007-2014 Intel Corporation. Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.0: added PHC on eth0 Jun 20 22:43:20 Ahri kernel: igb 0000:02:00.0: Intel(R) Gigabit Ethernet Network Connection

I'll DM you the password for the file, because I really don't feel comfortable putting up info like this publicly. https://drive.google.com/file/d/1Zw4NvfVu0YSxuaKYmTdsy01Xh85U45bR/view?usp=drivesdk If you decide to help me out you have all my thanks and appreciation in advance already. Cheers

I decided to reboot after noticing that my docker image was unreadable as well as /mnt/user/system and anything below it. I decided to reboot and now my cache pool of two drives won't mount. Brining my array into maintenance mode yielded me this on the read-only filesystem check against my cache pool: [1/7] checking root items [2/7] checking extents [3/7] checking free space tree free space info recorded 1351 extents, counted 1361 There are still entries left in the space cache cache appears valid but isn't 6182821691392 [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups skipped (not enabled on this FS) Opening filesystem to check... Checking filesystem on /dev/sdj1 UUID: d5b29014-e26e-4407-a52d-73db030f39ef found 759680454656 bytes used, error(s) found total csum bytes: 236747020 total tree bytes: 1881374720 total fs tree bytes: 1275772928 total extent tree bytes: 314228736 btree space waste bytes: 386624833 file data blocks allocated: 7470265802752 referenced 690431000576 Should I run the check without the read-only parameter? I will provide any diagnostics that are asked for, but I will not read megabytes of compressed files trying to censor them for privacy.

I'm sorry to generate a notification for you and not come around with an answer, but I just want to express that I'm wondering the exact same thing right now. I'd love to do this with a reverse proxy without giving a card-blanche to all containers.

Getting rid of the Docker tab sounds horrible and insisting on keeping that Action Centre enabled notification active is.... a really odd choice to be fair. Docker containers and plugins are not just different delivery algorythms to achieve the same in my honest opinion. Plugins typically extend the capability of the host OS and docker applications are more like user apps. To me those are severely differnt things. I'm really puzzled by those views. I also don't think having the app store and the app presentation of already installed apps as a unified place in one tab is major UX progress. More nesting does not always equal more simplicity and overview....

Tauchen die docker eigentlich auch als hosts im Netz sichtbar auf (z.B. im Router) wenn du keine Ports mappst? Oder behält Docker die dann für sich und lässt gut sein? Mir wäre es lieber wenn die Docker alle keine IPv6-Adressen hätten, sondern IPv6 nur auflösen und erreichen könnten. Also docker-internes IPv6to4 oder so. Aber wenn ich dann hinterher Dutzende Einträge mehr im Router habe dann sollls wohl so sein...

What did you set for PUID and PGID? Confirm it's the same as when you run this from the container's shell: id What you set and what displays there should definitely match, this is basically a sanity check for my template. Where I expect a deviation is your files as you already guessed. To confirm and fix in that case: From the container's shell again, run this command against the Uploads, Extensions and if applicable Database folders' mapped locations: ls -lh like so ls -lh /directus/uploads/ ls -lh /directus/extensions/ ls -lh /directus/database/ You only need to check the last one if you use SQLite rather than a dedicated database backend. To fix, if needed run this, should work from the container's shell again, if not, change the paths to the mapped host paths and run from unRAID's shell: chmod <PUID>:<PGID> -R /directus/uploads/ chmod <PUID>:<PGID> -R /directus/extensions/ chmod <PUID>:<PGID> -R /directus/database/ Lastly run this command against the same directories: chown 755 -R /directus/uploads/ chown 755 -R /directus/extensions/ chown 755 -R /directus/database/ That should do it 👍

No hard feelings, but tech heads aren't known to stop tech chatter willy-nilly. 👻

What's the problem? Templates don't change a lot, but when they do, I want to catch and handle it, semi-automatically if needed. I have dozens of containers. I agree that changed templates yeeting custom configs in them is bad, that's why I propose that template updates and user defined stuff should be merged git-style, but obviously that should be opt-in. I don't get why others want to tout their personal preference as the only way, I'm trying to think of both schools of thoughts, but whatever. In Portainer you can subscribe to a docker-compose.yml hosted elsewhere and override env variables with your own configs. when the yml changes, your overrides remain intact. (unless of course the name of the variable were to change, but that's a complete other can of worms, and I've never experienced that myself) In the end no solution is perfect, everything will involve user administering. But I really don't understand why my suggestion is so disagreeable when I say it should be optional. Fine you don't want to use it, don't.

How about queuing changes, displaying them as suggested and the user gets to confirm and apply or deny them? Best of both worlds and I have to spend less time troubleshooting.

@ich777 You raise excellent points there, one question though: when we see that needed local changes getting yote is the problem, why do we not tackle the problem at its root? IMHO unRAID should track your changes, stash and apply stash them. Git-style merges of local deviations. These sorts of problems have long been solved, the problem is that unRAID CA templates get updates in a way where settings are applied again, but not the template modifications.

I'm willing to do that, but if the template changes, it'd be a very good idea to have those templates versioned. At least on breaking changes. And for sure it should be automated when there's new path mappings offered. Reason being that you may end up writing into your docker image all of a sudden. Considering unRAID these days is typically recommended as "the go to" for simple, fully managed DIY NAS solutions you kinda have to account for maybe not user errors at every corner, but user laziness. Also, we all have personal lifes, sometimes you really can't keep up with your homelab for a while, if stuff that's important breaks in the meantime and you don't know what happened or why, that can spiral into a lot of wasted time. It's good that templates can use release notes, that they can be updated, etc... (although it's not the only platform offering this, Portainer can pull changes from a git-managed docker compose for example) However that doesn't mean it's unimprovable. As far as wishing for a deactivation of updates for templates is concerned, I doubt that's really feasible or needed. The underlying app's docker container won't suddenly not have those needed new mappings and the like just because the template doesn't define visual fields to fill for them. So I get if you're coming from that side and I may have misunderstood your entire post.

Wie mich IPV6 annervt... Ich will einfach nur dass meine container auch IPV6 WAN Adressen auflösen und erreichen können. Am liebsten wäre mir die Container behalten alle ihre IPV4 LAN ports und IPV6 läuft irgendwie nebenher aber ohne offene Ports und ohne BS. Sozusagen bridge mit IPV6 WAN "Durchschleifen". Warum ich das will? Naja, weil mir eine App einen HAUFEN an urlopen error [Errno -3] Try again Fehlern gibt. Manchmal klappen die Verbindungen, manchmal nicht. Daher glaube ich, dass das alpine Image versucht ne IPV6 zu erreichen. Es geht hier um Youtube und Twitch für einen Container mit yt-dlp, und das Problem habe ich seit Wochen. Ich habe ÜBERHAUPT keine Lust auf VLANs, neue IPs und was weiß ich für Container und Dinge, die auf sie zugreifen. -__-

Heyo Hmm, I really don't know the intricacies of JP encoding and WINE, which this uses. Maybe it's better to ask the creator of the docker image or even better the original creators of FMD2? So far I've only used it for pulling stuff where the filenames use English alphabet characters. The support links are as follows: Container's GitHub FMD2's GitHub

docker-fmd2 Dockerized FMD2 (Windows with Wine) using VNC, noVNC and webSocketify to display GUI on a webpage. This is an active fork of the Free Manga Downloader which is a free open source application written in Object Pascal for managing and downloading manga from various websites. (description from the application's author and the container's maintainer respectively) The application is in my experience a rock-solid way to download chapters for manga which are missing a license in your country yet and are free and legal to download. Check with your local laws to see what you can and cannot download using this application. Much like a browser, this app is a mighty tool and doesn't restrict you, you're responsible for your own downloading. The (unofficial) container wrapping the app in wine comes with a lightweight Ubuntu base image and downloads the latest FMD2 version available from the official repo. Support and Links beyond this template support's scope: Container's GitHub FMD2's GitHub Info A companion you might want to use is Manga-Tagger, a template for the unofficial container made by the same container maintainer will be made available soon as well, although unlike the original version of Manga-Tagger it does not rely on FMD2 and can be used standalone. You have to set file-naming options matching an expected scheme for that version of Manga-Tagger to work correctly though. [I am still waiting for some rather important (IMHO) changes to be made for Manga-Tagger before releasing it and pre-configuring it for you all with sensible defaults :)]

There is one available now. What's everyone using to tag their manga? Because the application doesn't (deliberately) make any use of folder structure which whilst maybe useful for it to not depend on it is a big drawback if you don't really have a nice way to tag your manga. I know there are tools like manga-tagger, but they are Windows-GUI-only and boy does it want a LOT of dependencies for a end-user oriented application. Set up a VM only for FMD2 and it, but manga-tagger refuses to function. Apparently there's a docker-template for manga-tagger of a fork that doesn't rely on FMD2, but I'm hesitant to try it out.

Hmm... Error response from daemon: OCI runtime exec failed: exec failed: container_linux.go:367: starting container process caused: exec: "/defaults/update.sh": permission denied: unknown Honestly the whole WebgrabPlus + TVHeadend stack is a pain in the butt. It's absolutely ridiculous that getting IPTV served up in your home actually causes more friction that using a hardware tuner for DVB-S/C/T...

Love you man, you're a machine! 😁

Chrome seems broken, the log just loops: ---Starting Chrome--- ---Starting Chrome--- /opt/scripts/start-server.sh: line 46: 91 Trace/breakpoint trap /usr/bin/chromium --user-data-dir=${DATA_DIR} --disable-accelerated-video --disable-gpu --window-size=${CUSTOM_RES_W},${CUSTOM_RES_H} --no-sandbox --test-type --dbus-stub ${EXTRA_PARAMETERS} 2> /dev/null ---Checking if UID: 99 matches user--- usermod: no changes ---Checking if GID: 100 matches user--- usermod: no changes ---Setting umask to 000--- ---Checking for optional scripts--- ---No optional script found, continuing--- ---Checking configuration for noVNC--- Nothing to do, noVNC resizing set to default Nothing to do, noVNC qaulity set to default Nothing to do, noVNC compression set to default ---Starting...--- ---Resolution check--- ---Checking for old logfiles--- ---Checking for old display lock files--- ---Starting TurboVNC server--- ---Starting Fluxbox--- ---Starting noVNC server--- ---Starting noVNC server--- WebSocket server settings: - Listen on :8080 - Web server. Web root: /usr/share/novnc - No SSL/TLS support (no cert file) - Backgrounding (daemon) etc etc... No VNC output to speak of other than "Failed to connect to server" Had always been working super fine for me before the latest update. (and of very great use to me, would hate to not be able to use it anymore!) Thanks so much for your work, @ich777! Have a great weekend everyone

Really glad that descriptions on cards are back, but boy do I not like the heavily reduced amount of items and being forced to look at overblown large cards. I take it the layout makes sense on touch devices, especially single-row views, but on desktop? Quite jarring to be frank. Too much scrolling, clicking "more", etc... Honestly? Old view is king in my books. The new side-loading panel for the details view is killer though, really appreciate that! Overall good work for sure, I love the amount of work that goes into this for sure, but desktop usage is (partially) nerfed.

No urgent need so I'd rather just wait. Got plenty of other stuff to take care of, so I'm gonna skip spending time on something that will for sure be figured out by someone else and that I'm gonna learn about relatively soon, so... yeah. But thank you for the feedback. Also, not a bad thing to have more unRAID learning material at your disposal.

Hmm, I'm hesitant to experiment and run into troubles and such. I'll wait for a spaceinvaderone video for this one, mostly because once he does one, it'll be a lot more used and hence (implicitly) expected functionality that Limetech might have to test for as well with future releases. I'd rather ride it slowly and know that docker-compose works PROPERLY before I fully commit to it. Good news for sure though!

👀 Are you gonna attempt to hack some way into this so I can manage compose'd containers in DockerMan? Or what is that reference to WebUI supposed to mean in the template description?

Soon™ is a trademark by Blizzard Entertainment. 🧐