clay_statue

Members
  • Posts

    24
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

clay_statue's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. I cannot access shares on unraid from my windows laptop. I have "remote access to LAN" and indeed my laptop can ping my unraid server and my router, so I do indeed have connection to devices on my LAN. I can also access my dockers webGUI's. The wireguard connection is working in every way *except* I cannot access my shares. Even if I type the network address into file explorer \\x.x.x.x\share it cannot access the share. I tried setting tunnels both with specified NAT port forwarding and going UPnP alternatively. No dice. Before OpenVPN was deprecated I was using it as a docker image and was able to get remote access to my shares no problem... so I dunno what's going on here? [SOLVED] Had to stop the array and add the wireguard network pool to Settings > Network Services > SMB > hosts allow = 10.253.0.0/24 After I did that I could manually enter \\serverip\share in File Explorer and then map the drive. Big success!
  2. I think this is the relevant part of the log file... Jun 22 14:07:16 FractalTower rc.docker: redis: started succesfully! Jun 22 14:07:53 FractalTower rc.docker: Plex-Media-Server: started succesfully! Jun 22 14:11:10 FractalTower ntpd[2153]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Jun 22 14:13:00 FractalTower root: Fix Common Problems Version 2021.05.03 Jun 22 14:13:01 FractalTower root: Fix Common Problems: Warning: Docker Application binhex-sonarr has an update available for it Jun 22 14:13:01 FractalTower root: Fix Common Problems: Warning: Docker Application nzbget has an update available for it Jun 22 14:13:01 FractalTower root: Fix Common Problems: Warning: Docker Application redis has an update available for it Jun 22 14:13:10 FractalTower root: Fix Common Problems: Error: Machine Check Events detected on your server Jun 22 14:13:10 FractalTower root: mcelog: ERROR: AMD Processor family 23: mcelog does not support this processor. Please use the edac_mce_amd module instead. Jun 22 14:13:10 FractalTower root: CPU is unsupported Jun 22 16:20:47 FractalTower webGUI: Successful login user root from 10.10.10.25 Jun 22 16:22:10 FractalTower root: Fix Common Problems Version 2021.05.03 Jun 22 16:22:12 FractalTower root: Fix Common Problems: Warning: Docker Application binhex-sonarr has an update available for it Jun 22 16:22:12 FractalTower root: Fix Common Problems: Warning: Docker Application nzbget has an update available for it Jun 22 16:22:12 FractalTower root: Fix Common Problems: Warning: Docker Application redis has an update available for it Jun 22 16:22:19 FractalTower root: Fix Common Problems: Error: Machine Check Events detected on your server Jun 22 16:22:19 FractalTower root: mcelog: ERROR: AMD Processor family 23: mcelog does not support this processor. Please use the edac_mce_amd module instead. Jun 22 16:22:19 FractalTower root: CPU is unsupported
  3. Fix Common Problems threw this rather alarming error and kindly suggested that I post my diagnostics in the forum for some help figuring out the hardware issue. Any insight would be appreciated... fractaltower-diagnostics-20210616-0052.zip
  4. SpaceinvaderONE's video on setting up mysql database for use by docker containers
  5. Cool and neat. Now I can run phoenix miner at the server level rather than inside my windows VM. Of course I lose the use of my GPU for actually powering my monitors in such scenario but using a thin client and running the windows VM (my daily driver) headless would get around that.
  6. I was fidgeting with my IOMMU groups trying to free up some USB ports and unbeknownst to me, unRaid had taken control over my quad-port nic that usually get stubbed and passedthru to my pfSense VM. This meant that my cable modem was rawdoggin' straight to my server for a short while (less then 10 minutes) before I noticed what was up and unplugged it for the remainder of the tinkering. How concerned should I be? I don't have unRaid very well locked down at all because it's supposed to be sandboxed safely in my LAN behind pfSense.
  7. Excellent. I was worried Google had shunted me to another dead-end thread (as it is wont to do), but this looks like the solution. Interestingly I had this exact same problem with the my Radeon 5700XT GPU, which has a different function for graphics and sound on the same bus. The xml file automatically puts each function on a different bus, which in essence is splitting single device that isn't supposed to be split. That's what's happening to our nic basically. For a more thorough explanation of this xml config issue see SpaceInvaderOne's video about advanced GPU passthrough techniques (under five minutes). Although this video is about GPU's, the issue and the solution are essentially the same.
  8. OMFG... this is the magic bullet that finally solved my wonky VM issues! I will be riding this wave of contentment and joy every time I get a clean shutdown from a VM for years to come. I've been having a heck of a time trying to get windows 10 to shutdown clean, it had been making unRaid freeze. Fortunately I could still execute a graceful shutdown because I deliberately left my keyboard on a non-passthrough USB controller. So although I was frozen out of the webgui and running headless, I could still blindly log into the terminal and type "powerdown". That probably saved me from hundreds of hard reboots and god knows how many hours of parity checks. For dunderheads like me who are still lost in the weeds and are desperately seeking further clarification I will spell it out in the excruciating detail I wish that I had... 1) Check your IOMMU groups for the number 1022:149c or 1022:1487 attached to a USB controller called "starship/matisse". If you are trying to pass that through, that's (at least part of) what's causing boot and/or shutdown problems with your VM. solutions... 2) Don't stub it and don't passthrough the entire controller, instead passthrough individual devices. This didn't work in my case because my Focusrite external sound card was giving me demonic sound unless I passed through the whole USB controller. (I also fell down the rabbit hole of fidgeting with MSI interrupts to no avail) or.... 3) Edit the /syslinux/syslinux.cfg file on your unRaid USB (don't use notepad, use notepad++ or wordpad if on windows). You will see the various unRaid boot menu options listed in there. Under the first menu option will be "append blehblehblehstuff initrd=/bzroot". That's where you need to put "pcie_no_flr=1022:149c,1022:1487" without the " ". If you typically boot from another menu option, put it there instead. In my case the file looked like default menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label Unraid OS menu default kernel /bzimage append pcie_no_flr=1022:149c,1022:1487 vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot label Unraid OS GUI Mode and so on... This worked to get windows shutting down nicely. However my Ubuntu VM was still not shutting down clean, even after appending the syslinux.cfg file. That's because this bug is a quirk between the linux kernel and this specific USB controller. Ubuntu was still flubbing the shutdown because it has more or less the same kernel as unRaid. So the final step is to get Ubuntu to behave itself... 4) Edit the Kernel Boot Parameters in /etc/default/grub by moving the cursor to the line beginning with "GRUB_CMDLINE_LINUX_DEFAULT" then edit that line, adding your parameter (pcie_no_flr=1022:149c,1022:1487) to the text inside the double-quotes after the words "quiet splash". (Be sure to add a SPACE after "splash" before adding your new parameter.) Click the Save button, then close the editor window. 5) sudo update-grub 6) restart ubuntu The earlier comments in this thread and the following three links are the source of everything I just described: https://forum.level1techs.com/t/attention-flr-kernel-patch-fixes-usb-audio-passthrough-issues-on-agesa-1-0-0-4b/151877 https://old.reddit.com/r/VFIO/comments/eba5mh/workaround_patch_for_passing_through_usb_and/ https://wiki.ubuntu.com/Kernel/KernelBootParameters
  9. So I watched the video but this apparently only works when primary vdisk location is set to "auto", in which case increasing the size is fairly straightforward. How do you increase the size of a manually assigned vdisk?? Near as I can tell if you set a manually assigned vdisk there is no way to increase it's size and the only way to increase capacity is to add a second vdisk (D:/ drive).
  10. So every time I shutdown a Windows VM, unRaid crashed and became inaccessible from the webGUI. I went through every "solution" I found available to me. Legacy vs UEFI, manually adding and altering the registry to allow MSI interrupts, uninstalling various device drivers... EVERYTHING. Turns out there is an issue with AMD GPU's when using double monitors. If both monitors are connected via DisplayPort things can get buggy. However, if you use one DP and one HDMI then somehow this works out nicely and VM's can shut down clean without crashing unraid. FYI The GPU in question was the Sapphire Pulse 5700XT
  11. Don't you hate when you finally find the thread with your exact issue and it just ends without a solution? I have a Windows 10 VM with GPU passthrough that shuts down cleanly no problem. However the Windows 10 VM that has GPU passthrough AND nvme passthrough crashes unraid. I can still do a graceful powerdown from the command line, because despite running headless unraid still accepts keyboard input so type "root / password / powerdown" will shutdown the system without having to do a hard reset. However it would be nice to figure out what about nvme passthrough is causing it to crash unraid when you shutdown the VM.
  12. Bingo! It was the card reader. This thread is solved.
  13. Yea, okay it's not the janky network setup. Even with a direct patch cable to the router it won't take an IP. I don't know if what is happening is because dhcpcd is screwing up. I checked /etc/dhcpcd.conf and swapped clientid for duid to see if that would help but it didn't. I know there is an issue with linux and the realtek chipset of my mobo's onboard LAN port. I solved it in Manjaro by blacklisting the driver r8169 in /etc/modprobe.d and installing an older driver r8125. However I saw that unraid uses the r8125 driver and it was working so I am skeptical that this is the issue, but you never know... Edit: I created an unraid trial USB using the newest unraid 6.9 Beta and that worked. The beta version has no trouble taking it's IP from the router and connecting to the internet like it should. The challenge now is to figure out how to update unraid on my existing flash drive without a working network interface. Or rebuild my system from scratch using the new trial USB and adding existing array to the new system without clearing them for the new arry....
  14. I am yet to have a wired connection to the internet for my tower. As an interim solution I am using a wifi extender to provide an ethernet port for the tower. I have 192.168.0.100 reserved on the router (static DHCP?) for unraid so it will always gets assigned the same IP whenever it boots. I don't know why unraid is refusing it, I'll try removing the reserved IP and just let it assign whatever it wants to see if that helps... This could be some something to do with my janky network setup, although it has been working fine for a few days (albeit slow). I think I need to go buy a 100ft ethernet cable and plug unraid directly to the router temporarily and see if it calms down the DHCP shenanigans. ps... This seems to be the crux of the issue Nov 8 06:57:27 FractalTower dhcpcd[1919]: br0: soliciting a DHCP lease Nov 8 06:57:27 FractalTower dhcpcd[1919]: br0: offered 192.168.0.180 from 192.168.0.1 Nov 8 06:57:32 FractalTower dhcpcd[1919]: br0: probing for an IPv4LL address Nov 8 06:57:37 FractalTower dhcpcd[1919]: br0: using IPv4LL address 169.254.111.46 So the router and unraid are actually talking to each other, but for some reason br0 refuses the IP that it's offered and just assigns IPv4LL instead. Why is br0 refusing the DHCP server?