Caldorian

Thanks Squid. For some reason, I swore that there was an actual "Done" text at the bottom of the script window when the script completed before.

Just updated my unraid system from 6.11.5 to 6.12.8. Now every time I perform some management action with my plugins (install a new one, upgrade an existing, remove/delete one), the script window does it's thing, and then at the end, gets stuck on the line "Executing hook script: post_plugin_checks". If I click done, everything responds like the action completed successfully. I've attached the diagnostics from the system. unevan-diagnostics-20240302-1642.zip

Trying to do some cleanup of files, and when I tried deleting a folder with 1000s of files in it, I started getting I/O errors: After that, I couldn't access the folder above the one I tried to delete, or the share that the folder was mounted in. I then found that I couldn't even get into one of the disks in my array from the terminal: I stopped the array, started it in maintenance mode and tried running a disk check with no options. It told me there were outstanding logs. So I restarted the array fully, stopped it again, started in maintenance mode, and ran the disk check again with no options. Below is the log from that check disk run (edited to remove redundancy): I've started the array back up and things seem functional. I can access data on my other disks without issue, and data outside the folder I was trying to delete seems to be intact. Are there any suggestions on how I should proceed?

Does this plugin implementation still cause issues when you have docker containers that run on br0 with their own IP address? On my server, I have several containers (swag, pihole, etc) that I run on br0 with their own IP address. Swag in particular will need to be able to connect with other docker containers running on a custom docker network. The other interesting configuration I have with my server is I have a wireguard outbound vpn setup, with a couple dockers connected to that route through it. I'm also running it all on 6.11.5 still if that matters.

Thanks. Not quite sure what you're trying to say with the first part of that sentence, but I was able to convert all my connections over to a different username in a standard format. Seems to be working better now then when I first tried to do it several years ago.

Several years ago when I first setup my unraid server, I followed these instructions to create a user on my server so that my Windows clients where I use a MS Account for login could access the unraid SMB shares directly without having to manually enter other credentials. Been working fine for several years now. Upgraded to from 6.10 to 6.11.1 this week, and this user can no longer access shares. Using other user credentials who's usernames are "normal" work fine, but the user who's name is in [email protected] format doesn't work. And it's not just from Windows clients. I would also use this user credential to access the server from my iPhone (either browsing shares with VLC to play some videos or with the Files app), and neither of these options work any more either. I have to edit my connections to user basic usernames. Can this please be investigated? Happy to supply whatever logs you want/need.

Makes sense. To update them all, would I just change the Repository on my existing container to the synonymous lscr.io repository, or would I need to remove and re-create/re-install the containers with the right one?

Thanks. Definitely something I should have thought of on my own, so a good reminder that I could do that. Unfortunately I've also got other containers where I don't have that control, or that it doesn't work (ie. binhex-sabnzbd)

A bit of a general question here: I've currently got a setup with this container where I've routed other binhex containers through it as specified by Q24-27 of the VPN FAQ. One issue I've run into this setup is that if I have multiple instances of a container I want routed through it (ie. radarr), I can't because I can't use alternate port mappings. I've also started looking at the new Wireguard tunnels available directly in unraid and routing dockers through it. How do these two methods compare to each other? Option 2 seems simpler and more flexible in being able to support multiple container instances. But is there something that I'd be loosing by going with it?

Going through and doing some reviews of my system after updating from 6.9.2 to 6.10.3, and I'm noticing that my linuxserver containers seemingly come from multiple repositories now: linuxserver, lscr.io, & ghcr.io. Looking in CA, any of the ones that aren't from lscr.io aren't recognized as being installed. Is there any explanation on what's going on? Should I remove and re-install them all so they're all from the lscr.io repository? IMO, the linuxserver repository is the more desired one as all those have an easy to read format of linuxserver/<container>. The other 2 get truncated when looking at them in Unraid as the names are too long (ie. "ghcr.io/linuxse...rseerr").

Just throwing my experience out there for people: I found that after I upgraded from 6.9.2 to 6.10.3, most of my binhex container /config folders were set to root:root, and refused to run. The only ones that were set to nobody:users were the ones that I've spun up in the last few months (the others are on the range of a couple years old now). Things seem to be running normally now on 6.10.3 after I chown'ed them to all be nobody:users. So this was probably related to something that's changed in these containers over the couple years, and some new docker permission/settings with 6.10 that then caused things to flip out.

Does anyone have any thoughts on how Cornelious' container compares to Hotio's? The one big thing I notice is all the extra mappings pre-defined in Cornelious' template, but most of them are all within the standard container appdata folder and seem like they'd be redundant. As well, how rapidly each one updates compared to when the base-docker image updates.

Sorry, I guess I wasn't clear; My SWAG/nginx configuration works fine, and I can access the webUI through the reverse proxy without issue. What I'm trying to update is my container-to-container configuartion (ie. sonarr to sabnzbd) so that the sonarr dns name/port is uses the reverse proxy rather then communicating with the target container directly. Mostly so that I can save myself a small bit of configuration in the future where I only need to update the RP, rather then every container that might use the target.

I was recently playing with @binhex's VPN containers, and following along with Q24-Q27 of his FAQ, managed to route a couple of my containers through the VPN container. Awesome. But one thing I noticed as I was removing port mappings on some containers and adding them to others was that modified port mappings weren't showing up on either the overall docker view, or the "Show docker allocations" section. So I was curious, what's the actual trigger for mappings to show up in those sections?

So a quick follow up; I managed to google and find the VPN docker FAQ, and was able to setup my sabnzdb dockers with the container:delugevpn option. Since the network type on it is set to None, I'm guessing I can reliably assume that it's outbound connections are going through the VPN tunnel without having to further test it to guarantee it? I've got one quick followup question; I've got swag infront of things to use as an internal-only reverse proxy so I can access my containers' web UIs with nice DNS names (ie. https://sabnzbd.mydomain.com). I'd love to be able to use those same DNS names for the app connections as well. ie. in Sonarr, my download client config for SAB is set with the local hostname and port (8080) of the docker container. If I try using the SWAG reverse proxy name and port (443, Use SSL), it doesn't work. Is this possible?