Andiroo2

I used to get a nice secure handshake and a long URL into the address bar, but lately I just have my server IP and a certificate warning. My Servers plugin is installed and updated, and the api report looks ok: <-----UNRAID-API-REPORT-----> SERVER_NAME: Tower ENVIRONMENT: production UNRAID_VERSION: 6.10.3 UNRAID_API_VERSION: 2.49.2 (running) NODE_VERSION: v14.15.3 API_KEY: valid MY_SERVERS: authenticated MY_SERVERS_USERNAME: Andiroo2 CLOUD: ok RELAY: connected MINI-GRAPH: connected ONLINE_SERVERS: Tower OFFLINE_SERVERS: HAS_CRASH_LOGS: no </----UNRAID-API-REPORT-----> Anything I should be checking, or is this the new default behaviour? I am using a Ubiquiti router if that makes a difference (I recall some issues with those posted in the past). Thanks!

I just fixed my grafana with brute force: chmod -R 775 /mnt/user/appdata/grafana Add --user 99:100 to Extra Parameters in the container settings

Anyone else having issues using the Grafana container since the 6.10 upgrade? In another thread on Docker permissions after the upgrade, some users are having permissions issues with existing containers post-upgrade: My Grafana error is: logger=ngalert.multiorg.alertmanager t=2022-05-25T09:34:45.41-0400 lvl=eror msg="unable to create Alertmanager for org" org=1 err="error writing file notifications: unable to create the working directory \"/var/lib/grafana/alerting/1\": mkdir /var/lib/grafana/alerting/1: permission denied" I've made various wholesale changes to the permissions on the appdata folder with no luck, but I think this error is happening with file access within the container.

Same issue here. Some of the containers can't write to their own files in Appdata. Grafana initially for me, but maybe others.

Follow up on this one. My Unifi setup had created an internal honeypot on 192.168.1.99, but this wasn't listed in the clients section of the router. This is why I thought it was available when I deployed Pihole to the same address. Just in case anyone else has this issue in the future with their Unifi setup.

I don’t see that message in the logs. See attached.

Quick note on the “Move all files from cache pool selected above” option. When running this, my turbo write doesn’t engage. Can the Mover Tuning plugin check for this setting and enable turbo write when moving one share? I have “force turbo write on during mover” set in Mover Tuning settings for regular moves. Thanks!

I just updated from 2.00.10 (working) to 2.00.13 and I'm getting this error: [ERROR] Tdarr_Node - [39mBinary test 3: mkvpropeditPath not working It was working on my previous version. My json is blank for all 3 of these binaries: "handbrakePath": "", "ffmpegPath": "", "mkvpropeditPath": "", Do I need to point it to a specific path?

Success! I deleted the ../appdata/pihole/ directory completely and pulled a new image. No go. Then I changed the IP from .99 to .98 and it worked. Something must be using .99 on my network already, even though my Unifi controller shows it as available. More research to come, but for now my backup Pihole is running. Thanks!

I just tried a fresh pull and still the same behaviour. I can't get the GUI to load, but the system reports positive status: pihole status [✓] FTL is listening on port 53 [✓] UDP (IPv4) [✓] TCP (IPv4) [✓] UDP (IPv6) [✓] TCP (IPv6) [✓] Pi-hole blocking is enabled ...and if I tail the log, I see activity: # pihole -t [i] Press Ctrl-C to exit 08:09:17: forwarded 197.1.168.192.in-addr.arpa to 1.0.0.2 08:09:17: forwarded 197.1.168.192.in-addr.arpa to 1.0.0.2 08:09:19: query[AAAA] diag.meethue.com from 192.168.1.103 08:09:19: forwarded diag.meethue.com to 1.1.1.2 08:09:19: forwarded diag.meethue.com to 1.0.0.2 08:09:19: forwarded diag.meethue.com to 1.0.0.2 08:09:22: query[PTR] 197.1.168.192.in-addr.arpa from 127.0.0.1 I just can't get the GUI to load to set it up fully. Screenshot of the docker page is attached. What am I missing?

For those that are coming here to troubleshoot a new Pihole docker setup in 2022, the app marked "Official" in Community Apps doesn't yet work on Unraid out of the box. The template being pulled from docker has changed and the Unraid template hasn't been updated to use the new/correct variables yet. There are some changes listed in the thread here that may get it working for you, but for now, don't pull your hair out if it's not working out of the box. If I'm wrong, please delete this post or flag it...I'm not a spokesperson for this docker template...just someone that has pulled some hair out and now (I think?) understands where things stand.

I'm seeing this error in my logs over and over: Dec 28 08:23:15 Tower root: Starting Samba: /usr/sbin/smbd -D Dec 28 08:23:15 Tower root: /usr/sbin/nmbd -D Dec 28 08:23:15 Tower root: /usr/sbin/wsdd Dec 28 08:23:15 Tower root: /usr/sbin/winbindd -D Dec 28 08:23:15 Tower wsdd[5326]: set_multicast: Failed to set IPv4 multicast Dec 28 08:23:15 Tower wsdd[5326]: Failed to add multicast for WSDD: Address already in use Dec 28 08:23:15 Tower wsdd[5326]: set_multicast: Failed to set IPv4 multicast Dec 28 08:23:44 Tower emhttpd: Starting services... Dec 28 08:23:44 Tower emhttpd: shcmd (101438): /etc/rc.d/rc.samba restart Dec 28 08:23:46 Tower root: Starting Samba: /usr/sbin/smbd -D Dec 28 08:23:46 Tower root: /usr/sbin/nmbd -D Dec 28 08:23:46 Tower root: /usr/sbin/wsdd Dec 28 08:23:46 Tower root: /usr/sbin/winbindd -D Dec 28 08:23:46 Tower wsdd[8659]: set_multicast: Failed to set IPv4 multicast Dec 28 08:23:46 Tower wsdd[8659]: Failed to add multicast for WSDD: Address already in use Dec 28 08:23:46 Tower wsdd[8659]: set_multicast: Failed to set IPv4 multicast Dec 28 08:24:19 Tower emhttpd: Starting services... Dec 28 08:24:19 Tower emhttpd: shcmd (101481): /etc/rc.d/rc.samba restart Dec 28 08:24:22 Tower root: Starting Samba: /usr/sbin/smbd -D Dec 28 08:24:22 Tower root: /usr/sbin/nmbd -D Dec 28 08:24:22 Tower root: /usr/sbin/wsdd Dec 28 08:24:22 Tower root: /usr/sbin/winbindd -D Dec 28 08:24:22 Tower wsdd[12383]: set_multicast: Failed to set IPv4 multicast Dec 28 08:24:22 Tower wsdd[12383]: Failed to add multicast for WSDD: Address already in use Dec 28 08:24:22 Tower wsdd[12383]: set_multicast: Failed to set IPv4 multicast Dec 28 08:24:40 Tower emhttpd: Starting services... Dec 28 08:24:40 Tower emhttpd: shcmd (101510): /etc/rc.d/rc.samba restart Dec 28 08:24:43 Tower root: Starting Samba: /usr/sbin/smbd -D Dec 28 08:24:43 Tower root: /usr/sbin/nmbd -D Dec 28 08:24:43 Tower root: /usr/sbin/wsdd Dec 28 08:24:43 Tower root: /usr/sbin/winbindd -D Dec 28 08:24:43 Tower wsdd[14670]: set_multicast: Failed to set IPv4 multicast Dec 28 08:24:43 Tower wsdd[14670]: Failed to add multicast for WSDD: Address already in use Dec 28 08:24:43 Tower wsdd[14670]: set_multicast: Failed to set IPv4 multicast Thoughts on where to start looking?

+1 for the H O T C A C H E.

Do I MV the files to /mnt/cache/<share>/ or CP them? Is that the correct path I should be targeting? When I want them to go back to the array, do I run mover, or MV/CP them pack to /mnt/disk#/<share>/?

My movies folder is set to use cache (cache:yes) until cache hits 90%, then mover runs. I’d like to move most of my Christmas movies back to the cache while they are in demand and save my array from spinning up. Can I move files BACK to the cache without forcing the whole share to Cache:Prefer? My cache is a raid1 pool, so I’m not concerned about protection for the files.