jonp

Hi Walter, I'll look into this. Thanks for bringing to my attention.

FYI I have a open message to our theme creator to take a look as this appears to be related to that combined with the forum software upgrade we recently performed.

Are there any symptoms you are noticing or just errors in logs?

You should be able to do this from the forum account settings page. Let me know if you can't.

Hi there, Please recreate this post in the pre-releases bug report board here: https://forums.unraid.net/bug-reports/prereleases/ General support forums are for those running stable releases only.

I'll work on that this week It shouldn't be a Windows-only thing.

Please disable any ad blockers or other services running in your browser that may interfere with the webGui. Let us know if after doing so the issue is resolved. This definitely feels like a browser-specific issue. Can you recreate the issue when using a different browser or device?

You might need to wipe the device using the wipefs command if there is a weird partition structure. All the best, Jon

Hi there, In short, yes, you can do this. As far as how Docker containers will operate, that would be dependent on the author of the container and whether or not they preserve that data. We can't speak to how applications will work in containers that we don't personally publish, so you'll need to rely on community support for that, but worse case scenario, you can continue to use your VM-based solution on Unraid using KVM. All the best, Jon

Hi there, It appears you are trying to do this on a system without an integrated graphics device. I see you have two GPUs in the system (a 1080ti and a 3060). If you're trying to use both of those with VMs, you'll need a 3rd device to provide graphics for the host itself or you can try following this advanced GPU pass through tutorial from SpaceInvaderOne: or

Hi there, Sorry to hear you're having problems. When you made the new boot drive, did you do that from scratch or did you simply copy the configuration over from your old drive to your new drive? All the best, Jon

Hi there, Please share your complete system diagnostics with us and your VM settings. Have you tried creating the VM pass through the GPU immediately before installing Windows? You shouldn't have to install Windows using the virtual graphics adapter. In addition, if your underlying hardware doesn't have a built-in GPU, this can also cause a problem. I would suggest checking out the videos from SpaceInvaderOne on YouTube for advanced GPU pass through techniques:

Thank you @bonienl! As always you are a rockstar!

Can anyone here help @Yvan with this request? My Docker networking expertise isn't as strong as some of you here ;-).

Will look into this...

It should be up there! https://podcasts.apple.com/us/podcast/uncast/id1566634831

Totally being honest here, I have no idea what a Docker shim even is ;-). Any additional insights you can provide would help me better triage this issue.

Hmm, gonna have to see if I can obtain a FLAC version. We use riverside.fm for recording which provides a wav or mp3 file, but no FLAC. That said, I have been messing around with Audacity a bit and could probably extract to FLAC from there, but if the original source is MP3 or WAV, not sure if that'll help. Send me a friend request on our discord server and let's connect on this!

Nice! Glad you found something to meet your needs. Never surprises me with this community ;-). As far as a backup solution goes, it's something we've talked about for years, but backup is an entire business in and of itself. There are a plethora of companies/solutions out there for this ranging from the basic like rsync to the enterprise like CommVault. And of course there are a million little variants and specialities in between such as Veaam for VM backups. And on top of that if we want to make use of features like btrfs snapshots or send/receive, that can further complicate things. So while we may eventually bring in a backup solution, that isn't a promise and in the meantime, you can probably find a variety of ways to backup your system with some basic Googling, but here's a nice write-up from our friend over at @spxlabs: https://www.spxlabs.com/blog/2020/10/2/unraid-to-remote-unraid-backup-server-with-wireguard-and-rsync

Definitely will be. Each episode will be a mixed bag. The first episode was just setting the stage for things to come and to act as a reference point for content we intend to cover in other episodes. 30 minutes is roughly the length we want to keep these to not drag on too long, though there may be exceptions for special guests/events. No transcripts and unless we can find an automated service to do that, I do not intend to provide them. I appreciate the desire to read, but for me to sit and literally transcribe everything said in an episode.......I'd rather watch paint dry I kind of see what you're saying, but I think the power savings you would potentially gain there would be so miniscule that it wouldn't add up to anything significant. We already only spin up the drive you need in order to read content as required, saving as much power as possible. For us to add this option to the cache would honestly confuse a lot of people and not add enough value to warrant marketing it as a feature. If your drives and SSDs were active 100% of the time, SSDs typically draw about 1/3 the power of an HDD (using rough numbers, let's assume 2 watts for active SSDs and 6 for active HDDs). When not in use, HDDs and SSDs barely draw any power. So it's only ACTIVE usage that you see this 66% reduction in power consumption. So let's say you watch 3 movies a day for a week straight, each movie being 2 hrs long. That's 6 hours of active use time. So for a single HDD, that's 36 watt hours and for an SSD that's 12 watt hours. Using a rough guideline of 10 cents per kilowatt hour, that's $0.0036 for a weeks worth of movie watching on HDDs and $0.0012 for SSDs. Extrapolate that to a full year (multiply by 52 weeks) and you have $0.19 for the HDDs and $0.06 for SSDs. Let's go even more aggressive and say you were utilizing your storage for 40 hours every week. Same math. 40 hours * 6 watts per hour = 240 watt hours per week. 240 watt hours * $0.0001 * 52 weeks = $1.25 per year 40 hours * 2 watts per hour = 80 watt hours per week. 80 watt hours * $0.0001 * 52 weeks = $0.42 per year These numbers just don't add up enough to make a meaningful difference in your power bill, but this is just some back of the napkin math. If you can present a mathematical argument to showcase where there is an opportunity for far greater savings, I am VERY open to hearing it.

Just a friendly reminder everyone, discussing how to circumvent other vendors licensing will get content removed / banned from this forum. Tread lightly here

Hi there, This could be due to the brand of device you're trying to use. Never heard of Inno3D before. They may have bad device firmware that doesn't like being assigned to a VM. I'm assuming that without the device assigned, the VM can be spun up and shut down as many times as you want. A simple test would be to replace the GPU with an alternate from EVGA or another quality brand (EVGA is recommended) and see if you can reproduce the same result. If so, there may be more to investigate, but if not, you'll at least know the issue is specific to the hardware you're using. If you want to try and gather more information on what is causing this issue, you'll need to connect a monitor and keyboard to the system's onboard graphics and boot into console mode. Login to the console with your root account and then type the following command: tail /var/log/syslog -f This will begin printing log events directly to your monitor. Now recreate the VM crashing issue and I bet you'll see some critical information posted to the screen that you can then take a picture of and post back here for us to analyze.

Remote access is a tricky thing to get perfect. Ultimately there is a sliding scale between convenience, security, and complexity in terms of how you can do it and the risks/costs that come with each method can vary. For example, let's say you go with a Wireguard solution on Unraid. By default, anyone connecting would have a full connection to the entire server, not just a single application. So for management access, sure, that is a more overall secure way of approaching this, but it comes at the added cost of needing to download and configure a VPN client for the devices you wish to use to connect. Might not be a big deal to you, but if you want the flexibility of being able to use ANY device with a browser to connect to your server, a VPN isn't going to serve that purpose if you don't have the rights to install apps on the device you want to use. Another consideration is the application you want to serve remotely. Plex can work with a VPN, but its far easier to use without one. Do you really want to walk your non-techie friends/family through how to connect to your VPN and use Plex? So for just the management side of things, I definitely think a full VPN tunnel is great, but if you need more flexibility or don't want to have to configure that, HTTPS is very solid.

Not related. Read that post though.

Hello Unraid Community! It has come to our attention that in recent days, we've seen a significant uptick in the amount of Unraid server's being compromised due to poor security practices. The purpose of this post is to help our community verify their server's are secure and provide helpful best-practices recommendations to ensuring your system doesn't become another statistic. Please review the below recommendations on your server(s) to ensure they are safe. Set a strong root password Similar to many routers, Unraid systems do not have a password set by default. This is to ensure you can quickly and easily access the management console immediately after initial installation. However, this doesn't mean you shouldn't set one. Doing this is simple. Just navigate to the Users tab and click on root. Now set a password. From then on, you will be required to authenticate anytime you attempt to login to the webGui. In addition, there is a plugin available in Community Apps called Dynamix Password Validator. This plugin will provide guidance on how strong of a password you're creating based on complexity rules (how many capital vs. lowercase letters, numbers, symbols, and overall password length are used to judge this). Consider installing this for extra guidance on password strength. Review port mappings on your router Forwarding ports to your server is required for specific services that you want to be Internet-accessible such as Plex, FTP servers, game servers, VoIP servers, etc. But forwarding the wrong ports can expose your server to significant security risk. Here are just a few ports you should be extra careful with when forwarding: Port 80: Used to access the webGui without SSL (unless you've rebound access to another port on the Management Access settings page). DO NOT forward port 80. Forwarding this port by default will allow you to access the webGui remotely, but without SSL securing the connection, devices in between your browser and the server could "sniff" the packets to see what you're doing. If you want to make the webGui remotely accessible, install the Unraid.net plugin to enable My Servers on your system, which can provide a secure remote access solution that utilizes SSL to ensure your connection is fully encrypted. Port 443: Used to access the webGui with SSL. This is only better than port 80 if you have a root password set. If no root password is set and you forward this port, unauthorized users can connect to your webGui and have full access to your server. In addition, if you forward this port without using the Unraid.net plugin and My Servers, attempts to connect to the webGui through a browser will present a security warning due to the lack of an SSL certificate. Consider making life easier for yourself and utilize Unraid.net with My Servers to enable simple, safe, and secure remote access to your Unraid systems. NOTE: When setting up Remote Access in My Servers, we highly recommend you choose a random port over 1000 rather than using the default of 443. Port 445: Used for SMB (shares). If you forward this port to your server, any public shares can be connected to by any user over the internet. Generally speaking, it is never advisable to expose SMB shares directly over the internet. If you need the ability to access your shares remotely, we suggest utilizing a Wireguard VPN to create a secure tunnel between your device and the server. In addition, if the flash device itself is exported using SMB and this port is forwarded, its contents can easily be deleted and your paid key could easily be stolen. Just don't do this. Port 111/2049: Used for NFS (shares). While NFS is disabled by default, if you are making use of this protocol, just make sure you aren't forwarding these ports through your router. Similar to SMB, just utilize Wireguard to create a secure tunnel from any remote devices that need to connect to the server over NFS. Port 22/23: Used by Telnet and SSH for console access. Especially dangerous for users that don't have a root password set. Similar to SMB, we don't recommend forwarding these ports at all, but rather, suggest users leverage a Wireguard VPN connection for the purposes of connecting using either of these protocols. Ports in the 57xx range: These ports are generally used by VMs for VNC access. While you can forward these ports to enable VNC access remotely for your VMs, the better and easier way to do this is through installing the Unraid.net plugin and enabling My Servers. This ensures that those connections are secure via SSL and does not require individual ports to be forwarded for each VM. Generally speaking, you really shouldn't need to forward many ports to your server. If you see a forwarding rule you don't understand, consider removing it, see if anyone complains, and if so, you can always put it back. Never ever ever put your server in the DMZ No matter how locked down you think you have your server, it is never advisable to place it in the DMZ on your network. By doing so, you are essentially forwarding every port on your public IP address to your server directly, allowing all locally accessible services to be remotely accessible as well. Regardless of how "locked down" you think you actually have the server, placing it in the DMZ exposes it to unnecessary risks. Never ever do this. Consider setting shares to private with users and passwords The convenience of password-less share access is pretty great. We know that and its why we don't require you to set passwords for your shares. However, there is a security risk posed to your data when you do this, even if you don't forward any ports to your server and have a strong root password. If another device on your network such as a PC, Mac, phone, tablet, IoT device, etc. were to have its security breached, it could be used to make a local connection to your server's shares. By default, shares are set to be publicly readable/writeable, which means those rogue devices can be used to steal, delete, or encrypt the data within them. In addition, malicious users could also use this method to put data on your server that you don't want. It is for these reasons that if you are going to create public shares, we highly recommend setting access to read-only. Only authorized users with a strong password should be able to write data to your shares. Don't expose the Flash share, and if you do, make it private The flash device itself can be exposed over SMB. This is convenient if you need to make advanced changes to your system such as modifying the go file in the config directory. However, the flash device itself contains the files needed to boot Unraid as well as your configuration data (disk assignments, shares, etc). Exposing this share publicly can be extremely dangerous, so we advise against doing so unless you absolutely have to, and when you do, it is advised to do so privately, requiring a username and password to see and modify the contents. Keep your server up-to-date Regardless of what other measures you take, keeping your server current with the latest release(s) is vital to ensuring security. There are constant security notices (CVEs) published for the various components used in Unraid OS. We here at Lime Technology do our best to ensure all vulnerabilities are addressed in a timely manner with software updates. However, these updates are useless to you if you don't apply them in a timely manner as well. Keeping your OS up-to-date is easy. Just navigate to Tools > Update OS to check for and apply any updates. You can configure notifications to prompt you when a new update is available from the Settings > Notifications page. More Best Practices Recommendations Set up and use WireGuard, OpenVPN or nginxProxyManager for secure remote access to your Shares. For WireGuard set up, see this handy getting started guide. Set up 2FA on your Unraid Forum Account. Set up a Remote Syslog Server. Install the Fix Common Problems plugin. Installing this plugin will alert you to multiple failed login attempts and much, much more. Change your modem password to something other than the default. Consider installing ClamAV. In addition to all of the above recommendations, we've asked SpaceInvaderOne to work up a video with even more detailed best-practices related to Unraid security. We'll post a link as soon as the video is up to check out what other things you can do to improve your system security. It is of vital importance that all users review these recommendations on their systems as soon as possible to ensure that you are doing all that is necessary to protect your data. We at Lime Technology are committed to keeping Unraid a safe and secure platform for all of your personal digital content, but we can only go so far in this effort. It is ultimately up to you the user to ensure your network and the devices on it are adhering to security best-practices.