xaositek

I'm not novice here but whenever I change the port from 8080 (to port 80) on the br0 connection, it still is not accessible over this port. I'm running 6.10-rc2 for reference.

@saarg I was curious has there been any discussion on an option for PHP 8 versus 7.4? I wanted to start testing it out safely without impacting the rest of my containers. Thanks in advance!

Unfortunately I gave up after multiple attempts. I'm now running https://mailinabox.email/ as a VM

Any option to update to 1.14 version of Tailscale? Looks like it's been available for a week or so. No rush and great project!

Changed Status to Closed

Changed Status to Solved

Fixed up my issues - great work sir!

That's because guys like yourself and @doron make amazing plugins!

Did confirm this fixed my issue in 6.10-rc1

Yes sir that fixed it immediately!

In my case FCP was already set to skip and the drives still won't spin down.

I was on 6.9.1

As of Wireguard App version: 1.0.13 (24) - iOS/iPadOS 15 and macOS Monterey now work properly. If you did NOT remove your configuration, it's an in place update and things will work. Otherwise import your tunnels from QR Code or Archive and you'll be good to go!

Warning for those of you who live on the edge of iOS updates and loaded the iOS 15 beta. From what I can tell, WireGuard VPNs don't presently work. I was able to get my backup VPN, which is a simple L2TP connection, working - but WireGuard is dead in the water. I did attempt to reprovision via QR code, but I think this is an issue outside of all of us.

Just a heads up - this isn't the first time we've been bitten by this issue. I personally always pop-open the GitHub page and check what the commits were to ensure it isn't this type of revert. GitHub: https://github.com/linuxserver/docker-unifi-controller You can see it happen here when it reverted from 6.2 to 6.1: https://github.com/linuxserver/docker-unifi-controller/commit/6eff0f3d19534437a2b3a823d47e94e8487f93cf

Downgraded to unRAID 6.9.1 and all drives immediately spun down after they wouldn't spin down all day under 6.9.2. Apr 8 20:43:00 cobblednas emhttpd: spinning down /dev/sdi Apr 8 20:43:00 cobblednas SAS Assist v0.85: Spinning down device /dev/sdi Apr 8 20:43:03 cobblednas emhttpd: spinning down /dev/sdf Apr 8 20:43:03 cobblednas SAS Assist v0.85: Spinning down device /dev/sdf Apr 8 20:43:03 cobblednas emhttpd: spinning down /dev/sdd Apr 8 20:43:03 cobblednas SAS Assist v0.85: Spinning down device /dev/sdd Apr 8 20:43:03 cobblednas emhttpd: spinning down /dev/sdg Apr 8 20:43:03 cobblednas SAS Assist v0.85: Spinning down device /dev/sdg Apr 8 20:43:03 cobblednas emhttpd: spinning down /dev/sdc Apr 8 20:43:04 cobblednas SAS Assist v0.85: Spinning down device /dev/sdc Apr 8 20:43:04 cobblednas emhttpd: spinning down /dev/sdh Apr 8 20:43:04 cobblednas SAS Assist v0.85: Spinning down device /dev/sdh Apr 8 20:43:04 cobblednas emhttpd: spinning down /dev/sde Apr 8 20:43:04 cobblednas SAS Assist v0.85: Spinning down device /dev/sde

Performed the same as SimonF for reference. root@cobblednas:~# date && cat /sys/block/sdf/sdf1/stat Thu Apr 8 13:05:17 CDT 2021 352 6073 57504 1456 549 6102 53208 7431 0 6344 8887 0 0 0 0 0 0 root@cobblednas:~# date && cat /sys/block/sdf/sdf1/stat Thu Apr 8 13:05:34 CDT 2021 352 6073 57504 1456 549 6102 53208 7431 0 6344 8887 0 0 0 0 0 0 root@cobblednas:~# date && cat /sys/block/sdf/sdf1/stat Thu Apr 8 13:06:38 CDT 2021 352 6073 57504 1456 549 6102 53208 7431 0 6344 8887 0 0 0 0 0 0 Apr 8 13:05:20 cobblednas emhttpd: spinning down /dev/sdf Apr 8 13:05:20 cobblednas SAS Assist v0.85: Spinning down device /dev/sdf Apr 8 13:05:26 cobblednas emhttpd: read SMART /dev/sdf

Fair point completely @SimonF. The research I had available to me across my two unRAID servers had limited this issue only to the server with SAS drives. My other unRAID box which has only SATA drives is working as expected.

I found this on my system as well across all my SAS drives. I've sent diagnostic info over to Doron who maintains the "Spin Down SAS Drives" plug-in.

Looks like something in unRAID 6.9.2 is resulting in drives not spinning down. Even trying to manually spin down doesn't help. Here's the Tools > System Log Apr 8 08:12:12 cobblednas emhttpd: spinning down /dev/sde Apr 8 08:12:12 cobblednas emhttpd: spinning down /dev/sdi Apr 8 08:12:12 cobblednas SAS Assist v0.85: Spinning down device /dev/sde Apr 8 08:12:12 cobblednas SAS Assist v0.85: Spinning down device /dev/sdi Apr 8 08:12:33 cobblednas emhttpd: read SMART /dev/sde Apr 8 08:12:33 cobblednas emhttpd: read SMART /dev/sdi Apr 8 08:15:15 cobblednas emhttpd: spinning down /dev/sdd Apr 8 08:15:15 cobblednas SAS Assist v0.85: Spinning down device /dev/sdd Apr 8 08:15:35 cobblednas emhttpd: read SMART /dev/sdd Apr 8 08:15:50 cobblednas emhttpd: spinning down /dev/sdg Apr 8 08:15:50 cobblednas SAS Assist v0.85: Spinning down device /dev/sdg Apr 8 08:15:56 cobblednas emhttpd: read SMART /dev/sdg Apr 8 08:18:26 cobblednas emhttpd: spinning down /dev/sdh Apr 8 08:18:26 cobblednas SAS Assist v0.85: Spinning down device /dev/sdh Apr 8 08:18:33 cobblednas emhttpd: read SMART /dev/sdh Apr 8 08:19:51 cobblednas emhttpd: spinning down /dev/sdf Apr 8 08:19:51 cobblednas emhttpd: spinning down /dev/sdc Apr 8 08:19:51 cobblednas SAS Assist v0.85: Spinning down device /dev/sdc Apr 8 08:19:51 cobblednas SAS Assist v0.85: Spinning down device /dev/sdf Apr 8 08:20:13 cobblednas emhttpd: read SMART /dev/sdf Apr 8 08:20:13 cobblednas emhttpd: read SMART /dev/sdc Apr 8 08:31:55 cobblednas emhttpd: spinning down /dev/sdi Apr 8 08:31:55 cobblednas SAS Assist v0.85: Spinning down device /dev/sdi Apr 8 08:32:18 cobblednas emhttpd: read SMART /dev/sdi Apr 8 08:42:14 cobblednas emhttpd: spinning down /dev/sde Apr 8 08:42:14 cobblednas SAS Assist v0.85: Spinning down device /dev/sde Apr 8 08:42:35 cobblednas emhttpd: read SMART /dev/sde Apr 8 08:45:17 cobblednas emhttpd: spinning down /dev/sdd Apr 8 08:45:17 cobblednas SAS Assist v0.85: Spinning down device /dev/sdd Apr 8 08:45:21 cobblednas emhttpd: read SMART /dev/sdd Apr 8 08:45:52 cobblednas emhttpd: spinning down /dev/sdg Apr 8 08:45:52 cobblednas SAS Assist v0.85: Spinning down device /dev/sdg Apr 8 08:46:13 cobblednas emhttpd: read SMART /dev/sdg Apr 8 08:48:28 cobblednas emhttpd: spinning down /dev/sdh Apr 8 08:48:28 cobblednas SAS Assist v0.85: Spinning down device /dev/sdh Apr 8 08:48:50 cobblednas emhttpd: read SMART /dev/sdh Apr 8 08:49:53 cobblednas emhttpd: spinning down /dev/sdf Apr 8 08:49:53 cobblednas emhttpd: spinning down /dev/sdc Apr 8 08:49:53 cobblednas SAS Assist v0.85: Spinning down device /dev/sdf Apr 8 08:49:53 cobblednas SAS Assist v0.85: Spinning down device /dev/sdc Apr 8 08:50:27 cobblednas emhttpd: read SMART /dev/sdf Apr 8 08:50:27 cobblednas emhttpd: read SMART /dev/sdc Edit: I did privately send Doron all diagnostic information to troubleshoot this.

Take the glory!! It's awesome work and thank you to @ljm42 for calling it out! I've been using this daily since I stood up my second unRAID server and the craftsmanship is great. I updated and was able to reissue keys for my four devices in less than 10 minutes.

Noticed I can view messages but I can not longer delete messages. Here's the log files (logs on a recreation so time stamps are a bit off) and a screenshot. ==> mail.log <== Mar 19 11:10:22 ce466793ae2b dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=192.168.55.11, lip=127.0.0.1, mpid=14851, TLS, session=<LugE9OW9toLAqDcL> Mar 19 11:10:22 ce466793ae2b dovecot: imap([email protected])<14851><LugE9OW9toLAqDcL>: Error: Mailbox INBOX: link(/data/domains/mymailserver.info/xaositek/Maildir/cur/1615003435.M382342P32606.3b20f19fac1b,S=6950,W=7251:2,S, /data/domains/mymailserver.info/xaositek/Maildir/.Trash/tmp/1616170222.M693717P14851.ce466793ae2b) failed: Function not implemented Mar 19 11:10:22 ce466793ae2b dovecot: imap([email protected])<14851><LugE9OW9toLAqDcL>: Logged out in=155 out=1173 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 Mar 19 11:10:22 ce466793ae2b dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=192.168.55.11, lip=127.0.0.1, mpid=14856, TLS, session=<It0F9OW9uILAqDcL> Mar 19 11:10:22 ce466793ae2b dovecot: imap([email protected])<14856><It0F9OW9uILAqDcL>: Logged out in=318 out=4258 deleted=0 expunged=0 trashed=0 hdr_count=6 hdr_bytes=1802 body_count=0 body_bytes=0 ==> mail.warn <== Mar 19 11:10:22 ce466793ae2b dovecot: imap([email protected])<14851><LugE9OW9toLAqDcL>: Error: Mailbox INBOX: link(/data/domains/mymailserver.info/xaositek/Maildir/cur/1615003435.M382342P32606.3b20f19fac1b,S=6950,W=7251:2,S, /data/domains/mymailserver.info/xaositek/Maildir/.Trash/tmp/1616170222.M693717P14851.ce466793ae2b) failed: Function not implemented ==> syslog <== Mar 19 11:10:22 ce466793ae2b dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=192.168.55.11, lip=127.0.0.1, mpid=14851, TLS, session=<LugE9OW9toLAqDcL> Mar 19 11:10:22 ce466793ae2b dovecot: imap([email protected])<14851><LugE9OW9toLAqDcL>: Error: Mailbox INBOX: link(/data/domains/mymailserver.info/xaositek/Maildir/cur/1615003435.M382342P32606.3b20f19fac1b,S=6950,W=7251:2,S, /data/domains/mymailserver.info/xaositek/Maildir/.Trash/tmp/1616170222.M693717P14851.ce466793ae2b) failed: Function not implemented Mar 19 11:10:22 ce466793ae2b dovecot: imap([email protected])<14851><LugE9OW9toLAqDcL>: Logged out in=155 out=1173 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 Mar 19 11:10:22 ce466793ae2b dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=192.168.55.11, lip=127.0.0.1, mpid=14856, TLS, session=<It0F9OW9uILAqDcL> Mar 19 11:10:22 ce466793ae2b dovecot: imap([email protected])<14856><It0F9OW9uILAqDcL>: Logged out in=318 out=4258 deleted=0 expunged=0 trashed=0 hdr_count=6 hdr_bytes=1802 body_count=0 body_bytes=0

unRAID is Slackware based, not FreeBSD. Anyone feel free to correct me if I'm wrong, but I don't believe this changes it for us.

Mistakenly attempted to add a new peer yesterday and the whole thing came crumbing down. I removed the entire /boot/config/wireguard folder, uninstalled the plug-in and tried again. Now when I try to create my initial tunnel, the page just refreshes but no settings are saved. The /boot/config/wireguard folder is not made either. What (and where) are the logs that would be relevant to troubleshooting this issue? I can post them pretty quick. Edit: Figured out that some remaining iptables entries in the FORWARD rule and also the WIREGUARD chain all together was still lingering after the uninstall. So I deleted those two items and rebooted. Now it's working!!