ljm42

You would need to contact your ISP to get a new WAN IP. Be sure to setup a custom/random WAN Port for the server: https://docs.unraid.net/connect/remote-access Or disable the port forward if you don't want to use it any more.

I'm not super clear on what the problem is, but if you can ping the server then as long as you know the http or https port you should be able to access the login screen using your browser.

I am glad your issue appears to be resolved! This thread was for a very specific issue, so if your issue comes back please start a new thread with all the details, as that would mean it is not similar enough to have the same solution being discussed in this thread.

If there are errors, they will be logged in /var/log/notify_Discord . You can view the log with: cat /var/log/notify_Discord If you post the info here I may be able to help parse it.

This sounds like something else is going on, I'd recommend starting a new thread with details of your issue.

Please upload your diagnostics.zip (from Tools -> Diagnostics). Any NIC passed through to a VM would not be visible to FCP, so there must be something else triggering the notification.

Something is holding your zpool open, but it doesn't appear to be the docker.img: Jul 27 15:15:42 Tower emhttpd: Unmounting disks... Jul 27 15:15:42 Tower emhttpd: shcmd (154432): /usr/sbin/zpool export cache Jul 27 15:15:42 Tower root: cannot unmount '/mnt/cache/system': pool or dataset is busy I'd suggest starting your own thread, I don't think you are hitting the issue this thread is about, and there are other things that are more concerning: Jul 26 20:06:09 Tower kernel: critical medium error, dev sdh, sector 3317704632 op 0x0:(READ) flags 0x0 phys_seg 72 prio class 2 Jul 26 20:06:09 Tower kernel: md: disk0 read error, sector=3317704568 I'm not an expert on that but hopefully someone else can lend a hand.

See if this thread helps: https://forums.unraid.net/topic/79981-solved-unraid-wont-boot-from-usb-after-reboot-restart/#comment-991877

Interesting. I don't see a way to split this conversation into a new bug report, so please create a separate bug report for this. The more info you can provide the better. Such as, what is the make/model of the UPS, what was the last version that shut it down, etc.

The snippet you posted looks fine

This log is currently limited to 10MB, so it isn't going to fill your log partition on its own. In the next release we are going to cap it at 2MB IIRC

I just ran a test in 6.12.3 and apcupsd stopped the array and shut down the server without issue when the "Runtime left to initiate shutdown" condition was met. In terms of turning off the UPS, it depends on whether your UPS supports the APC command for that or not. I have a Cyberpower UPS and it does not. For more about this, see https://forums.unraid.net/topic/38606-apcupsd-settings-does-not-seem-to-shut-down-ups-solved/#comment-375297

In the short term, please disable IPv6 if you can. We are working on some fixes and will ask you to install a test release when it is ready. Aside from that, please install the Fix Common Problems plugin and see if it has any suggestions for you.

If you are still on 6.12.1, please upgrade to 6.12.3 and provide diagnostics ( << click the link ), preferably after the problem happens Depending on the problem, these may help: /etc/rc.d/rc.php-fpm restart /etc/rc.d/rc.nginx reload

What version are you comfing from? Your SSL port is set to 80443, but the max is 65535 Carefully edit the config/ident.cfg file on the flash drive and change this line: PORTSSL="80443" to something else, like: PORTSSL="40443" (or any other number between 1000 and 65k that isn't in use by a Docker container) Then reboot the system. Based on your settings, the webgui should be available at these urls: http://192.168.1.75:8080 http://Tower.local:8080

Your symptoms are not the same. Please start a new thread with your specific issues and include your diagnostics.zip ( <<< click the link )

This is not related to the recent bug fix. Most likely, you had a SSH or a web terminal open and cd'd to the cache drive, like this: root@Tower:/mnt/cache/appdata# If desired, you can install the Tips and Tweaks plugin, by default it will automatically kill any ssh or bash process when you stop the array. There are other potential causes too, see https://forums.unraid.net/topic/69868-dealing-with-unclean-shutdowns/ If your normal workflow regularly gives unclean shutdowns, I'd get in the habit of stopping the array first before restarting. That will give you a chance to see the "Retry unmounting disks" message in the lower left corner and start investigating.

Very odd. See this for running diagnostics from the command line: https://docs.unraid.net/unraid-os/manual/troubleshooting/#system-diagnostics

Sounds like we're talking about the Remote Access feature? That is just for the webgui. To access to Docker containers or other items on your network you'll want to use a VPN https://forums.unraid.net/topic/84226-wireguard-quickstart/

It won't help you now, but this was discussed in the first post in this thread, bullet 3 in particular. Now that you are on 6.12.3 this cause of unclean shutdowns won't happen.

The cache drive concept exists because writes to the Unraid array are comparatively slow. When writing new files they can go to an SSD cache drive and then get copied over to the main array of spinning drives overnight when nobody cares how long it takes. I'm curious what benefit you see of putting an M.2 cache drive in front of a ZFS pool of NVME drives. Direct writes to the ZFS pool are going to be very fast, putting a cache drive in front of that doesn't get you anything that I can see.

diagnostics showing a call trace in the two nic setup in the other thread would be helpful (this provides both a syslog and configuration information to help determine what the problem could be) Please also enable syslog mirroring to flash to capture logs if it does crash (this would be in the logs folder on the flash drive, ideally you also would have diagnostics from before the crash to show the configuration)

Hopefully it was clear from my earlier response, that is the goal : ) This was just a side conversation... I see a lot of "I can't do XYZ because of Fritzbox" so I'm just wondering if people have the ability to replace it with a better router or if they are locked in to using it.

OK so first let me acknowledge that these macvlan call traces are an issue, and we are looking for a fix. Having said that, I think the recommendations here are valid until we have something better: https://docs.unraid.net/unraid-os/release-notes/6.12.0/#known-issues 1) IPVLAN may not work for everyone, but it is a simple thing to try. I think you don't like it because your router can't do port forwarding when IPVLAN is enabled. OK, that is a bummer. Side note - one thing I keep meaning to ask folks is does your ISP *require* you to use the Fritzbox or are you allowed to replace it? In the US, ISPs give you a pretty bare bones router but you are usually allowed to replace it if you want more functionality. Not sure if it works that way everywhere or not. 2) As far as I know the two nic solution should work. If there are issues with it in 6.12.3, it would be great to have that discussion (including diagnostics!) over in this thread: https://forums.unraid.net/topic/137048-guide-how-to-solve-macvlan-and-ipvlan-issues-with-containers-on-a-custom-network/ So far I haven't seen any diagnostics from 6.12.3 that say we shouldn't recommend this as a way to avoid macvlan call traces. It may end up depending on the hardware involved. Anyway, probably best to keep that discussion in that thread. If those solutions aren't ideal for you then you can try to ignore the call traces, but if your system ends up crashing that isn't good. At that point you can take another look at the solutions above or roll back to a previous version. Be sure to read the 6.12.0 release notes if you do decide to roll back.

Your flash drive has errors, looks like that is preventing the file from being written to it: Jul 19 13:01:31 NAS kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 400e4138) Jul 19 13:01:31 NAS kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 400e4138) Jul 19 13:01:31 NAS kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 400e4138) Jul 19 13:02:31 NAS kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 200e0e43) Jul 19 13:02:31 NAS kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 200e0e43) Jul 19 13:02:31 NAS kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 200e0e43) Jul 19 13:02:31 NAS kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 400e4138) I'd recommend putting the drive in a Windows computer and running chkdsk, It may work after that. You should also make a backup and get a new flash drive on order ASAP in case this fails completely, in which case see https://docs.unraid.net/unraid-os/manual/changing-the-flash-device