Glassed Silver

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.