jonp

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.

Hi there, What you'll need to do is stop both the Docker and VM Manager services (located on the Settings Docker and settings VM Manager) pages. With those services disabled, you should manually move all the data off your SSD in the array to your HDDs in the array. Then when that completes, you can stop the array and perform a "New Config" operation from the Tools page. Set it to preserve disk assignments and when done, go back to the main tab. Now your SSD will still be assigned to the array, but the box to the left will be Blue instead of Green, indicating that you can DEASSIGN the device. Then you can reassign that SSD to the cache pool and start the array. Once the array is started, you can then bulk copy all of the data back from the array disk(s) to the cache. Last step will be to ensure that all of the paths for your containers/VMs are still pointed correctly but after that, you should be good to go!

Hi there, Saw your emails into support. Unfortunately I'm not super familiar with Krusader and how it may affect the storage space represented on the system. If you try copying from a standard Windows or Mac machine, do you have these problems? Exporting /mnt/user isn't currently supported functionality, and oddball behavior like this could be the result of it. Why not just create one single share called "share" and use that one share?

Hi there and thanks for completing that task and getting the diagnostics updated. I've honestly never seen those particular messages in a server before, so we will need to do some investigating to see what's going on.

Hi there, Let's try booting 6.9.2 in safe mode and disable all docker containers for the time being. See if that works. If so, start turning containers on one at a time, giving ample time for the issue to occur in between, until you've been able to reproduce the issue. Then we can look more specifically at that container to see what's wrong. If none of them give you an issue, it may be an issue with a plugin. Either way, we need to step through the troubleshooting to figure out what's causing your problem.

Hi there, As an FYI, I wouldn't have reported this as a "bug" just yet, as this could be something amiss with your system. If this was a bug related to Samba, I'm fairly certain we'd have a plethora of users reporting the same thing. The first thing I'd like you to try is rebooting in safe mode. See if you can reproduce the issue in that mode. If so, please reattach your diagnostics after you've reproduced it in safe mode so we can review again. Thanks.

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, Well that's a new one! Can you please attach your system diagnostics? And silly question but is your Internet connection dropping? What kind of network equipment do you have? Have you tested cables to ensure that isn't the issue either?

Hi there, The easiest solution for most is to have a secondary GPU for pass through and the primary GPU for the host OS. That said, there are video guides how you can attempt to pass through a GPU on a system with only one:

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.

@lnxd is right. It's not to say there aren't some special hoops you can jump through to potentially make your card work, but it's not in the cards for us at Lime Tech to figure that out as each card might have different challenges and different solutions. Its far easier for us as a company to simply state: modern NVIDIA devices (specifically EVGA brand) work great, but AMD cards may have various issues depending on the exact make/model and vBIOS revision.

Hi there, AMD systems are notorious for having issues with GPU passthrough. I would suggest first replacing the GPU with an NVIDIA device which now has official support for this use case.

Hi there, Have you tried this:

Seconding what @itimpi has stated here, we will be updating docs to reflect best practices. Thanks for bringing this to our attention and please, continue to make us aware of anything that is confusing, inaccurate, or out of date with the wiki.

OMG! I'm so glad you finally got this working. I was at my wits end trying to figure out how to guide you further. Glad you have a working system now!!

I'm really still at a loss on what's causing your issues. I haven't been able to reproduce this in any of our testing systems. I do have a VM running on pc-i440fx-4.2 but I would honestly be shocked if it started exhibiting issues as this is a fairly common scenario. The VM's machine type version doesn't automatically get updated for the VM when we update QEMU, but QEMU can respect that. Its even more odd since these are simply VNC-based virtual machines. Typically when there are VM issues, its due to something hardware-specific with PCI-device pass through. If that's not happening here and we're talking about just a basic headless VM, I'm at a loss. What would be helpful is when these issues occur if we could get a fresh set of diagnostics with you on 6.9.1.

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.

I looked at the logs / diagnostics, but I didn't see anything that gave me a clue, but perhaps @ljm42 can take a peak?

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.

Hi again, Looking at your diagnostics, I see the following HBA's installed on your system: 00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake PCH SATA AHCI Controller [8086:a352] (rev 10) DeviceName: Onboard - SATA Subsystem: ASUSTeK Computer Inc. Device [1043:8694] Kernel driver in use: ahci Kernel modules: ahci 02:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03) Subsystem: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] Kernel driver in use: vfio-pci Kernel modules: mpt3sas The latter of which is being stubbed by the vfio-pci driver. Navigate to the Tools > System Devices page and uncheck that controller from being stubbed, save the setting, then reboot.

A few questions for you: 1) Did you have a root password set on the server before all of this happened? 2) Was your server at all exposed to the Internet? 3) Do you have any other users on your network locally that could have "done something" to the server (e.g. is this server on a network shared with other users you don't necessarily "trust" like a school LAN or something)? In addition, it would be helpful if you could find a way to attach your system diagnostics. If you cannot connect to the webGui because of the 502 error, you could try SSH. Use Putty to create an SSH connection to your server, login with root, and when done, type "diagnostics" and press enter. Then you can poweroff the server, remove the flash, and plug it into a mac/PC. In the root of the flash you will find a diagnostics ZIP that you can then attach here for us to review.

Hi everyone, Thank you for your patience with us on this and @bonienl for taking point on trying to recreate the issue. We are discussing this internally and will continue to do so until we have something to share with you guys. Issues like these can be tricky to pin down, so please bare with us while we attempt to do so.

Hi there Totally understand your request and why you would want a fully documented backup solution. There are plenty of different tools out there to utilize for backups. There have been a number of different guides written from different individuals on how to do this. We even wrote a blog post recently detailing one (https://unraid.net/blog/unraid-server-to-server-backups-with-rsync-and-wireguard). The reality is that backup is a business in and of itself. There are plethora of different providers out there that create various software solutions that work with various platforms such as Unraid. If we ever do create a first-party solution for backups for unraid we will obviously document it but until then we do rely on the community and other backup software solution providers to provide guidance. That being said, we may end up creating a guide under our wiki in the future, but no ETA on when that will happen just yet.

Does your server have a root password set? Is your server directly exposed to the internet (is your server in the DMZ or do you have port 80/443 forwarded to your server's IP)? If the answer to question 1 is yes and the answer to question 2 is no, then I doubt someone has hacked your server. Without the root password or network access to the server, there is just no way someone can "sniff a NIC" (whatever that means) and gain access to your system. I also don't see any events in your logs that point to a hacker. Atypically we would see a lot of SSH connection attempts which all get flagged and I don't see any in your logs. That being said, if you don't use usernames/passwords for share security (meaning anyone on your network can browse the files on the server), then ANOTHER machine on your network could have been compromised and used to attack the Unraid box. What I would suggest is to slowly re-enable docker containers one by one. Maybe one per day if you can afford to wait that long. Start with the server running with no containers and see if permissions change again randomly. If not, move on to the next container and start that one. Perhaps one of those containers is doing something to the permissions causing the issue. In addition, I would also suggest booting into safe mode so you can eliminate any plugins from the equation.