grigsby

Thank you!

This plugin is great. Super useful. Thank you for making and supporting it. I have a question about the warning generated for containers that don't have any local storage, like glances and dozzle. Appdata Backup gives the following warning when there's no local storage to back up: Event: Appdata Backup Subject: [AppdataBackup] Warning! Description: Please check the backup log! Importance: warning dozzle does not have any volume to back up! Skipping. Please consider ignoring this container. I don't want to ignore or skip the container because I still want Appdata Backup to update the container during the backup run. Is there a good way to configure things so this warning isn't generated, but without skipping the container so it still gets updated? Thank you!

Man, I really struggled getting the nvidia driver plugin reinstalled after upgrading to 6.10.3. The problem was that I'm an idiot. Also, maybe a slight problem with the plugin installer user interface? I followed all the instructions here -- removed the plugin using 'rm' at the command line, rebooted about 40 times, and kept trying to reinstall the plugin from community apps. The problem arose because the plugin installer status window would get to the line that says "Package nvidia-driver-2022.05.06.txz installed." And then the window/text would pause and do nothing for 30-60 seconds. So at that point I thought the driver was installed and rebooted. I never waited for the plugin to actually finish installing. I did this about 10 times. The problem was I never saw the *next* part that says: "WARNING - WARNING - WARNING... Don't close this window ... until the Done button is displayed!" But it took soooo loooong for that text to be displayed, I never saw it. I didn't figure out that the process wasn't finished until I saw other people's screenshots here on the forum. I wonder what's happening between the "Package... installed" and "WARNING - WARNING" that caused such a long delay? If there's some call there that can be moved/removed so the WARNING WARNING comes up immediately, it sure would have saved me a couple hours of going around in circles and rebooting too soon. Of course, once I actually waited until the whole thing was *actually* finished and the Done button finally appeared, it all worked great.

Hi all. I'm having a problem with the most recent homer docker container updates (https://hub.docker.com/r/b4bz/homer). The problem is described by others here: https://github.com/bastienwirtz/homer/issues/441 Basically, there was a change in the docker compose file, so the latest container doesn't work on Unraid. The error is that the container runs as the incorrect user and group, so the container doesn't have read/write permissions for the appdata folder. Adding the normal PUID and PGID environment variables doesn't work, I think because the docker compose file expects to see something in the form of "-user 99:100". Also, having the appdata folder owned by root didn't help either. I can't figure out how to update the Unraid docker template, or how to get the latest homer containers to work. For now, I've just set the tag to b4bz/homer:22.02.2, which was the last version that worked before the repo changed the format of the docker compose. Any ideas? Thank you!

Thank you for these directions. Super easy! All (34?) of my containers started up without a problem.

Influxdb 2.x doesn't work with these containers. The API or authentication system is significantly different than in 1.8. I haven't really looked into trying to fix it, because it was just easier to stick with 1.8. In the Influxdb docker container, change the repository to "influxdb:1.8.4" and things will work again.

Same problem here.

OMG. Thank you! I feel dumb now. That was driving me crazy.

EDIT: I'm now pretty sure it's a problem with pfSense 2.5.0's NAT port forwarding, not Unraid. But still, if you have any ideas, I can still use the help! At this point I'm just going to try to downgrade pfSense to 2.4.5. Ugh. I previously wrote: ---------------snip----------- Hi all, I have a bunch of docker containers that were all working perfectly for a long time. (The typical stuff like Plex, Overseerr, geth, etc.) I had been running Unraid 6.8.3 and pfSense 2.4.x with port forwarding. Everything was peachy. A couple days ago I upgraded to pfSense 2.5.0 and Unraid 6.9.1, and now none of my port forwards work anymore. 😞 When I check the packet state on pfSense, they show "NO_TRAFFIC:SINGLE" for udp and "CLOSED:SYN_SENT" for tcp connections. From what I can figure out from searching for this problem, this means that the Unraid server is not responding to the packets correctly. The few answers I've found online seem to indicate that it has something to do with the server not having a correct default gateway or route for the answering packets. I have checked every setting I can think of. I am almost certain the problem is not with pfSense, since it is forwarding packets correctly. I'm almost sure it's that Unraid -- in particular, Unraid's docker and/or network configuration -- is not sending reply packets correctly. I have no idea what I should try next. If you have any ideas, please share! All of my docker services are now unavailable outside my network until I get the port forwarding problem figured out. 😞 Thank you! Scott

Neither the USB creator app nor the manual install script is working on MacOS Catalina 10.15.4. SIP disabled, and the app has full disk access. USB drive is formatted FAT32 and named UNRAID. The script make_bootable_mac doesn't even look like it would work right -- it appears to be copying files to/from the wrong places. I'm pretty good with this stuff, but it's extremely difficult (impossible?) to make a bootable USB stick on a Mac running Catalina right now. I eventually gave up and used my kid's Windows box to make the USB drive. I'm still really looking forward to bringing my first unRAID box online!