ljm42

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

I would expect them to be listed on your Plugins tab. If not, please upload your diagnostics.zip (from Tools -> Diagnostics) Note that is really not advised to run rc releases so long. You should upgrade to 6.11.5 or 6.12.3

We are absolutely looking for ways to get macvlan to work without throwing call traces. Currently our best advice is documented in the known issues for 6.12.0: https://docs.unraid.net/unraid-os/release-notes/6.12.0#known-issues 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.

We will definitely announce when this feature is available

I really appreciate people posting about their experiences. But without diagnostics we have no way to begin to investigate. Note: we don't really need diagnostics about normal macvlan call traces, but if you get call traces with the solution discussed in the first post of this thread, we definitely need to see diagnostics.

Be sure to follow the first post here very closely: https://forums.unraid.net/topic/84316-wireguard-vpn-tunneled-access-to-a-commercial-vpn-provider/

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.

So the system must be on the network since you can access its webgui. Since it can't connect to the Internet that sounds like either a bad gateway or DNS server. Go to Settings -> Network Settings and see if statically setting the DNS server to 8.8.8.8 helps.

Follow the whole guide in the OP, including the "Testing the tunnel" part

Odd. Does it help to make a dummy change to the WG config and apply? If not, Diagnostics might be helpful

The "Peer DNS server" setting isn't really applicable when in "VPN tunneled access" mode because Peer settings apply to Peers, not Unraid itself. Best to follow the guide in the OP

Please provide updated diagnostics, the previous ones are from 6.12.2

The Unraid files are stored in the root of the flash drive (all the bz* files + changes.txt). Your config info is stored in the config directory. It honestly sounds like you somehow restored the flash drive from an old backup. Is there any way you can figure out if that is the case? The ideal thing would be to recreate the flash using the correct files. You can change the Unraid version replacing the bz* files + changes.txt with a different version following the instructions here: https://docs.unraid.net/unraid-os/manual/upgrade-instructions#manual-upgrade-or-downgrade but I'm more concerned about your config, specifically making sure the right drives are assigned for the array and cache.

hmm, IPv6 should work in 6.12.3, but as a test let's go ahead and disable that (Settings -> Network -> use IPv4 only), then reboot and upload fresh diagnostics. thanks

If you are still on 6.12.1, please upgrade to 6.12.3 Have you gone through everything in the first two posts here? https://forums.unraid.net/topic/84226-wireguard-quickstart/

We really need to see your diagnostics.zip ( <<< click the link ) to be able to troubleshoot anything. Edit: hmm you said you can't pull diagnostics once the problem happens. Well, diagnostics from when it works might be helpful, and if you could post the syslog after the problem happens that would fill in the details

diagnostics ( <<< click the link ) please

It is weird, the server initially boots as Tower and then it changes to NAS. Don't think I've seen that before: Jul 18 15:59:39 Tower emhttpd: shcmd (1013490): NAME='NAS' ; hostname ${NAME//[^a-zA-Z\-\.0-9]/\-} Jul 18 15:59:39 Tower emhttpd: shcmd (1013491): hostname -s >/etc/hostname Jul 18 15:59:39 Tower emhttpd: shcmd (1013492): echo '# Generated' >/etc/hosts Jul 18 15:59:40 Tower emhttpd: shcmd (1013493): echo 127.0.0.1 $(hostname -s) localhost >>/etc/hosts Jul 18 15:59:40 Tower emhttpd: shcmd (1013494): /usr/local/emhttp/webGui/scripts/update_access Jul 18 15:59:40 Tower root: sshd: no process found Jul 18 15:59:42 Tower emhttpd: shcmd (1013496): /usr/local/sbin/update_cron Jul 18 15:59:42 Tower emhttpd: shcmd (1013497): /etc/rc.d/rc.rsyslogd restart Jul 18 15:59:44 NAS rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="24790" x-info="https://www.rsyslog.com"] start Jul 18 15:59:44 NAS emhttpd: Starting services... Jul 18 15:59:44 NAS emhttpd: shcmd (1013500): /etc/rc.d/rc.samba start I'm guessing something on the flash got corrupted. Can you put the flash drive in a Windows computer and run chkdsk?

Does it help if you set the container to not autostart, then go to Settings -> Docker and disable the Docker service, then enable it?