Jump to content

ljm42

Community Developer
  • Content Count

    1444
  • Joined

  • Last visited

  • Days Won

    7

ljm42 last won the day on January 19 2018

ljm42 had the most liked content!

Community Reputation

121 Very Good

2 Followers

About ljm42

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  • Personal Text
    the answer to life, the universe, and everything

Recent Profile Visitors

1995 profile views
  1. Another vote for PhotoSync. Set it and forget it, both Android and iOS
  2. CAs are not allowed to generate a certificate for https://192.168.1.199 because that would work on many computers, it does not uniquely identity one machine. They can however generate certs for any Fully Qualified Domain Name (i.e. xyz.unraid.net), and there is no restriction on what IP address the DNS for that FQDN actually points to. Your browser is able to connect to http://192.168.1.199 because it is an insecure connection, no SSL cert required. Unraid responds and redirects to the proper FQDN for the https connection. Your browser refuses to connect to https://192.168.1.199 (regardless of port) because the browser is asking for a secure connection and Unraid doesn't have a certificate that matches "192.168.1.199" (per the comment above). Since your browser refuses to make an https connection without a valid cert, it never finds out that Unraid just wants to redirect it to the proper FQDN
  3. Here is a tip from: Create a file called startup.nsh in the root of the flash drive which contains the single line below: \EFI\boot\bootx64.efi
  4. Open the file in a good editor (such as Notepad++ , not Notepad) and save it with Unix line endings (LF) not Windows line endings (CR LF)
  5. I typically shut my system down carefully, by first stopping the VMs, then stopping the array, then powering down. Today I went straight for "stop array" and ended up with an unclean shutdown. Some research brought me to this helpful post by @dlandon: Basically, these settings must be in sync to get your system to shutdown gracefully: "Settings->VM Manager->VM Shutdown time-out": must be long enough to allow your VMs to shutdown "Settings->Disk Settings->Shutdown time-out": must be long enough for the array to stop *after* VMs have shutdown. So 60 to 120 seconds longer than the VM timeout. "Settings->UPS Settings->Time on battery": must be short enough that the system will have enough power to stay on for the entire "disk settings shutdown time-out" Additionally, "Settings->UPS Settings->Turn off UPS after shutdown" seems extremely risky and should only be used if you know your UPS will stay on longer than the "disk settings shutdown time-out". I don't see any options to configure this. Currently the UI provides no help in tying these settings together. So the request is: Adjust the UI so that it won't allow you to set the disk settings shutdown timeout less than the VM shutdown timeout (plus perhaps a minimum additional delay?) Adjust the UI on the UPS Settings page to make it clear that you need to trigger the shutdown early enough to allow the system to run for at least as long as the "disk settings shutdown time-out" Add a warning telling users they probably don't want to enable the "Turn off UPS after shutdown" option It may be worth adding a new "Settings->Powerdown" page that contains all of the relevant settings in one place A secondary request for @Squid: updating the UI to help people put in reasonable values is great, but will only help if you are looking at those screens. Perhaps FCP can alert the user if these settings are out of sync?
  6. Just FYI - A few versions back Unraid added a robots.txt file, which should keep legitimate search engines from indexing a server that is placed on the Internet.
  7. Please see this guide: AFAIK it details the best way to run Unraid as a guest on an Unraid host.
  8. Very cool @Squid! FCP is awesome for this type of proactive notification No false positives here.
  9. @Squid is this something Fix Common Problems could detect?
  10. hmm... git doesn't seem to be installed in 6.7.0? root@Tower:~# git -bash: git: command not found root@Tower:~# whereis git git: root@Tower:/var/log/packages# ls git* /bin/ls: cannot access 'git*': No such file or directory
  11. This thread was obsoleted three years ago, but I went ahead and updated it to acknowledge that issues with transcoding to RAM may have changed since then. If you'd like to discuss that topic I'd suggest visiting the Plex: Guide to Moving Transcoding to RAM thread.
  12. If it works for you, great! But if you start having issues with Plex, this is the first thing I would change.
  13. Looking at top.txt file in your diags, Plex was indeed using 100% of your CPU at the time you generated your diagnostics: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5958 nobody 20 0 1314160 75948 36220 S 100.0 0.9 13:52.16 Plex Medi+ see this I didn't recognize that, but a Google search for "unraid ACPI BIOS Error" says it is harmless, although you might try checking for a bios update: https://forums.unraid.net/topic/75337-acpi-bios-errors-in-syslog/
  14. It is a valid question, the Linux drivers for those cards may not be included in Unraid. If nobody can give you a direct yes or no, I would do a Google search for "unraid x470" and "unraid 10gbe" to see what you can find
  15. I have had mixed results with https://ipaddress . At a minimum you will need to bypass the browser warnings telling you that the certificate doesn't match the url. http://ipaddress will automatically redirect to https://hash.unraid.net . If your computer hasn't cached that address already and your Internet is down, it won't be able to do a DNS lookup, which causes the issue you are seeing. One solution is to add an entry to your local hosts file that points hash.unraid.net to the correct IP address. The downside is that this overrides DNS, so you need to remember to update the hosts file if the IP address ever changes. Another solution is to disable SSL by editing the /boot/config/ident.cfg file and changing USE_SSL to "no", then typing "powerdown -r" from the console to reboot. When it comes back up you will be able to use http://ipaddress to access the gui.