ryoko227

Members
  • Posts

    161
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by ryoko227

  1. Not sure if I'm the only one, but when I click support in the Docker drop down menu, it takes me to the old support page located here https://forums.unraid.net/topic/41631-support-linuxserverio-openvpn-as/ Just a heads up
  2. ^ that is basically what I ended up doing. Luckily I can pass through the USB controllers on my MB. Never any issues anymore.
  3. Home Server running AMD 1920x updated from 6.6.7 => 6.7.2 with no issues or modifications needed o/ Thank you as always!
  4. Couldn't update to 6.7.0 without hosing my system (in that update thread). Decided to try again adding ... iommu=pt before updating to 6.7.2, and was able to move over with no issues from 6.6.7! System seems snappier and looks great. Happy to finally be on the 6.7.~ line. \o/
  5. Oh, dang, I was hoping for some juicy tidbits, sorry for the confusion. Thank you though, I can also confirm that the APs don't seem to have any issue when “Override inform host with controller hostname/IP” are with the FQDN, just the USG that's WAN IP is where the FQDN resolves to. I'm gonna see if I can find a way to json the inform information and hard lock them to something that works. ---------SOLVED---------- https://www.reddit.com/r/Ubiquiti/comments/bxrzoh/usg_setinform_fqdn_gives_local_usg_adopt_loop/ This is how I made the config.gateway.json... { "system": { "static-host-mapping": { "host-name": { "FQDN": { "inet": "My_unRAID_Local_IP" } } } } } Since it's running in unRAID, I could simply place this into... /mnt/cache/appdata/Unifi_Container_Name/data/sites/Site_Name_Being_Used
  6. Sounds like something specific on my side then. So I checked the USG's config.boot and its showing "hairpin-nat enable" in the port forwarding section. I then verified that the FQDN resolves internally, pointing to my WAN IP, which it does. So I checked my firewall and porting forwarding to try and make sure I don’t have anything silly in there. Everything is default, aside from my port forwarding stuff for the inform, stun, and an old OpenVPN docker I had setup. From there I started searching and found something about forwarding ports 443 and 10443, but that also didn’t work. I even forced a DNS entry for that FQDN => local unRAID IP, which worked for all devices except the USG, which would still come back with the WAN IP, and then adopt loop. Thinking something was off, I created another docker container completely from scratch, no backup restore, set-default all devices, this time using 5.8.30 on the controller. Same issue, if I don’t “Override inform host with controller hostname/IP” when the docker/unRAID server restarts, the devices go into an adoption loop. One thing I did notice that I thought was odd is if you SSH into the devices and use “info” while its looping, it’s showing an inform set to the docker container IP, not the previously set/working inform information. I really don’t have any idea why the USG isn’t liking the FQDN as its inform. I have pulled power, set-default, used the reset button, everything back to factory, and it still hates it. If I set-inform to the local unRAID server address, it immediately connects. Did you have to do anything special to get your's working with an overiden FQDN? Outside of that, I am extremely curious if there is a .json way to hard-lock the inform information on a per-device basis. That's kind of the last ditch effort , as this is looking like my only/easiest option.
  7. Coming off of the deprecated 5.6.40 controller which had no issues, now I am seeing the same adopting issues as many others have mentioned on 5.6.42, 5.8.30, etc. Unfortunately, I cannot use the "Override inform host with controller hostname/IP" work around as I have USGs in other sites that use a FQDN to inform the controller, which I have found the above workaround does not work with. Things I have tried and noticed. Override inform host with controller hostname/IP – using FQDN ・Offsite no issues connecting, local devices adopt loop ・From ^ SSH into the local devices, set-inform manually to the controller’s local IP, it will connect, then when it re-provisions those local devices to the FQDN forced hostname, it starts looping again Not using override - after restarting unRAID ・Offsite that had been set previously with FQDN inform, connects with no issues ・Local devices adopt loop. Like above, setting the inform manually via ssh to the controller’s local ip works immediately I am using a site-to-site tunnel, and according to unifi, the tunnel should auto update the WAN address, keeping the connection alive. So I’m wondering if forcing the inform to the local ip of the controller will work or not. I don’t know, even if it does, I don’t like that idea of having only a single point of failure, with the probability of loosing access to that offsite site. I’m curious if maybe making a json file, setting the local device’s informs to the controller’s local IP address, if that will be like ssh’n into them manually stopping the loop or not. Just an idea that popped into my head, but I wouldn’t know how to do that, even following the unifi “make a json” instructions. If anyone has any other ideas, I am open to them. Otherwise, I might have to try and get the 5.6.40 controller back up and running again (if that is even possible with it being deprecated). Updated---- Tried rolling back to 5.6.40, same issue there now. Not sure whats causing it. I mean, everything still works (aside from the controller) after a reboot, so I suppose it will just be a minor annouyance of manually set-inform'n for awhile until things get sorted out.
  8. Unfortunately, upgrading from 6.6.7 to 6.7 grenades my unRAID. In reference to the system in my signature named Yokohama Server, after updating I got something similar to... DMAR:[DMA Read] Request device [04:00.0] fault addr DMAR:[fault reason 06] PTE Read access is not set can't find bond device. It assigns the server a completely out of range IP, and the webui isn't even available via the GUI boot option's localhost. Thinking this is an issue with IOMMU based off previous posts, I decided to try rebooting with VT-d disabled in BIOS. Server came right up, no errors in the logs, no issues at all (aside from not being able to passthrough devices to my VMs). I checked with MSI, and they haven't released a new BIOS for this MB since 2018 (already on the current version). I require passthrough on this server, so have had to revert back to 6.6.7
  9. Sorry, quick question, how does one go about doing this? (also having the same issue as the previous "update") EDIT- I removed the image, then tried docker pull linuxserver/openvpn-as:2.6.1-ls11 Which seemed like it gave me the previous version (just fumbling about using google here). However, still have the same issue. EDIT 2- Removed that image, added the container again via the unRAID GUI, changed the repository to "linuxserver/openvpn-as:2.6.1-ls11", worked like a charm! Back up and running ^_^v
  10. This is all really good info! Sorry the OP got hacked, but it's helpful to see a "what not to do" case. I tried something similar once on a test rig, dropping the unRAID IP into the DMZ.... OMG! The literal NON-STOP SSH login attempts were insane. Needless to say, that test rig got a complete wipe after that experience. Back on point though, @Abnorm I just wanted to bounce this off you since it seems related to what the OP is trying to fix and also to make sure that I'm doing this correct. I have a OpenVPN docker, with the default port forwarding setup on the router, and named via duckdns. Is it relatively safe to assume, that unless someone finds a vulnerability in OpenVPN itself, that this rather standard method should be predominantly secure?
  11. Updated both servers from 6.6.2 with no issues to note o/
  12. Just a follow up to this, since I thought it was weird and also so when I forget what I did I can check back later, www So I never got around to running the memtest, partially out of laziness, mostly out of not wanting to stay after hours. I noticed yesterday, that the mounting point for the drive no longer seemed to have any files or folders in it. So I tried copying the backups over just to see, and it said the disk was full... I decided I would try reformating the drive (again just to see) and pulled the mount commands from the go file and rebooted. Drive showed up totally fine in Unassigned Devices, could mount with no issues, and all the files and folders were still there. So, I set it to automount, changed my VM settings to point to this new mounting point, and profit. EDIT - Even with mutliple reboots nothing has changed... weird Everything seems to be running fine and I have had 0 checksum errors since. Keeping in mind, I did the 6.6.3 update right before all of this. So TBH, I don't know what "fixed" it, or even what was ultimately wrong with it. I know I should still run the mem test to verify
  13. Ya, unfortunately more errors started cooking off, so I pulled it and am doing a parity-sync as we speak. Man, once it started to go, it just really went. Was 600~ this morning, was almost 2,000 by the time I pulled it. Thanks for the input o/
  14. After this weekend's parity check I got a spam of errors on the parity drive related to "Reallocated sector count, Reported uncorrect, Current pending sector, and Offline uncorrectable". According to the SMART Attributes, they all seem related to old age or pre-fail. Interestingly enough, the parity check itself produced no errors, but I'm going to guess that reallocation of sectors maybe avoided that? Anyways, it seems self evident, but I thought I would ask here anyways. These are all signs of that the drive is on its way out and will most likely fail in the near future, correct? I intend to replace the drive immediately (as its on a production machine), but how long would you guy's temp fate by leave this thing in or using it in another machine? Keeping in mind, the reallocated sector count Raw value was 648.
  15. Should I try running memtest or something to troubleshoot it further? I'm thinking that might help with trying to sort out which piece of hardware might be causing it. I'm also going to check and see if there is a new BIOS for this specific motherboard as well. Thank you as always for your help johnnie! EDIT- Updated the BIOS as it specifically had increased memory compatiblity listed. Also took the time to clean the dust out and reseat everything. Still popping the error. I'll run memtest on it later when people aren't using it and see if that identifies/finds the issue.
  16. This and a multiple varients of this error are getting spammed across my system log since updating to 6.6.0 BTRFS warning (device sdb1): csum failed root 5 ino 274 off 62905892864 csum 0x2d8eafc5 expected csum 0xea417956 mirror 1 The device in question is a singular SSD mounted outide the array via the go file at startup. Running stats on the device results in this [/dev/sdb1].write_io_errs 0 [/dev/sdb1].read_io_errs 0 [/dev/sdb1].flush_io_errs 0 [/dev/sdb1].corruption_errs 0 [/dev/sdb1].generation_errs 0 Scrubbing the device also gives 0 errors. scrub started at Thu Sep 27 14:24:13 2018 and finished after 00:05:14 total bytes scrubbed: 153.88GiB with 0 errors I have copied all of the data off and reformated the device. (This did have the added benefit of UD plug-in now showing the: FS, temp, and capacity). However, the errors continue. I've read quite a few posts related to this, but still haven't found a solution on my own. I admittedly don't know enough about the btrfs file system to understand which file(s)/metadata are causing the error. Any help would be greatly appreciated. Thank you in advance o/ yes-mediaserver-diagnostics-20180927-1436.zip
  17. Can confirm upgrading BIOS fixed this issue for my MSI x399 SLI PLUS mother board as well.
  18. Based off of what I have not found in my own searching, and reddit comments as well, I think the only "only costs time" setup, would maybe be to setup something like... (thinking out loud here, tossing ideas out, feel free to add or comment on it) Setup VM3, to be started by the unRAID "Virtual Machine Wake On Lan" app by dmacias72 Setup VM1 & VM2 with a streaming option (something like OBS??) to broadcast the video and audio via LAN. envec h.265 or something. Would need some direction in this area as I am not a streamer ^^; Create a short batch shortcut on VM1 & VM2 allowing for one click booting of VM3 ^ Setup within this batch an autostart script for the (insert streaming solution here) locally Setup VM3 startup batch/script to view these streams PBP, fullscreen, in 4K Profit? I suppose VM3 could even be a docker or something. I don't think it would even need to be a Windows OS, probably would just depend on what software is used to combine the video/audio streams. Maybe OBS again using the incoming streams as inputs for the display? I'm kindof think of this being something akin to twitch, but locally. Tossing ideas out there, what do you all think?
  19. Less an unRAID specific question, but I'm hopeful someone here has done something similar. What I would like to do... I would like to have 2 of the VMs in my unRAID server box be able to display simutaniously, side-by-side video (preferably at 1080p 60fps or more) on a 60" 4K TV. Audio mixed if possible (wireless headsets are also ok). Plan on playing via PS4 controllers &/or mouse & KB. I would like it to be as automatic as possible. ie-switch to that TV input and both displays are already up and showing/ready for whatever. ie-playing Dead by Daylight via Steam side-by-side on the couch. What I have... unRAID already setup with gaming VMs - H/W passthough (GPUs, usb controller, etc.) A TV that will NOT side-by-side display from HDMI inputs (and no DP) >.<; Current options & thoughts... 1) Buy a $100+ HDMI mixer | pro - easiest (just plug and play) / cons - pricey, most don't seem to mix audio (1 at a time) 2) Capture & stream the 2 VMs video, maybe to a 3rd VM or Docker with dedicated gpu (have another 960 laying around) to display? 3) HW wise the server has more than it needs to do virtually any option. I would prefer to use the hardware I have without having to buy more equipment if possible, but I would really love some suggestions from anyone out there who has done something like this, or has some ideas of how to do something like this. Thanks in advance!
  20. I was just about to make a thread to send you guys at LT praise on the new branding and forums. I absolutely love the dark theme and stylizing. I understand to each their own, but I for one am loving it. Give the person or people who put this all together a well earned pat on the back!
  21. The website, forum, 6.6, moves, OMG! Too much unRAID goodness at one time! Loving the new styling; looks good guys. Keep up the great work!
  22. That's too bad. Not sure what might be causing the other issue you are running into, sorry bout that
  23. Most likely what is happening is that efi-framebuffer is being loaded into the area of memory that the GPU is also trying to use when unRAID is booted in UEFI mode. This thread explains the who, how, what, why and how to fix it if your issue is the same as mine was.
  24. @PSYCHOPATHiO out of curiosity, did you update to the newest BIOS for the Asus board? I've found that when unRAID is doing really weird and unexplainable stuff that its generally related to the BIOS.