kennelm

I have an Ubuntu VM that's been running solid for a long time. The other day, I needed to pass a new USB capture device from the host, so I modified the VM settings to set the checkbox for that device. At first it complained about a v2 or v3 compatibility issue, so I moved the device to a non-blue (presumable, 2.0 slot), and tried again. Long story short, after a couple of host and VM reboots to make sure everything was stable, the VM now boots in to the UFEI shell, and I can't figure out how to get past that. Appreciate any recovery advice you can offer. I have backups of the VM image and FD file if it comes to that, created by a community script signed by jtok. I've never restored from that backup, so that will be another investigation. lol Larry Update: I was able to create a new (blank) VM, then paste in the xml from the backup, copy the backed-up vdisk over to the standard location, copy the fd file to the standard location, modify the xml to point to those new files, and then boot up! Larry

All, I'm struggling with file system permissions and the Wife Acceptance Factor is going downhill fast. I have storage set up on unraid with multiple shares that indicate the purpose. The one in question is "pictures", mainly because it is viewed and updated in multiple places. First, I'm running an unraid VM that mounts "pictures" as a 9p filesytem. On that VM, pictures are added/updated. On various Windows clients, "pictures" is mounted via SMB and from there pictures can be added/updated. On the unraid server, files generally show up as owner=nobody, group=users, 766. But not always. On the Windows boxes, I followed the advice posted on these forums and defined smbuser as a user on unraid, then defined that user in the Windows Credentials Manager. I thought this would finally fix the issues, be we still have problems with permissions. If I create file abc from the Windows machine, I get this on the unraid server: -rwxrw-rw- 1 smbuser users 0 May 29 22:05 abc This seems mostly right I think. From the VM, if I touch file xyz in the pictures directory, I see this from the point of view of the unraid server: -rw-rw-r-- 1 1000 1000 0 May 29 22:01 xyz User and Group 1000 are undefined AFAIK. And then the permissions exclude write access to Other. Maybe I need to set a umask to get the right permissions? Or an ownership setting to avoid user 1000? Obviously, these differences in ownership/permissions lead to big-time problems. How can I reconcile user 'nobody' with user 'smbuser' and also deal with the VM writing files as user/group 1000? I need to be able to make changes to the pictures from the VM, and also from the Windows machines. With seamless ownership/sharing. Help appreciated. larry

I was behind on HomeAssistant versions and that was the issue....

I've been running the official HA docker container (network type=host) along with the builtin Wireguard VPN with no issues, until recently. I'm now on v6.12.4, so not sure if that upgrade may have introduced this issue, but if I have Wireguard VPN started, it causes the HA docker container to become unusable. It sure looks like it totally breaks the network for that container, but not others. Any thoughts on this much appreciated!!

Is the issue here the difference between dockerhub and github? Not everything in github is in dockerhub, correct?

I'm an idiot. Somehow, my vdisk migrated from the cache drive to the array. I moved it back and that did the trick. Squid, to your point about the protected array being 4x slower, I was seeing 2 orders of magnitude of slower progress with inserts/updates to the database. Sent from my SM-G975U using Tapatalk

Yes, I should have been more clear that I've been experimenting, moving shares back and forth from cache to the array (and forcing the mover to run after making changes). Am I wrong to believe the mover will handle the shift from one place to the other based on the cache settings for the share? I thought I observed that behavior when I changed the settings and forced the mover to run. Sounds like you are pretty certain that the slow performance is due to NOT being on the cache drive? I wondered if there are other settings I need to look into. Larry

Hello, I have terrible MariaDB insert/update performance on an unRaid VM running Ubuntu 20.04 LTS. The virtual image is stored at /mnt/user/domains/ which I've tried both on cache disk (btrfs) and within the array (xfs). Is there something obvious I should be looking for? As a test, I installed the MariaDB docker image and the data directory is on spinning disks (/mnt/usr/appdata). Tests reveal this database is much faster than the same database on the VM. In both cases, the same unRaid server (i7-8700K, 32GB RAM) is the host machine. Thoughts appreciated. Larry tower-diagnostics-20220618-1155.zip

I've been running OpenVPN via Unraid docker for some time and it works great. I just noticed that WireGuard is being offered as a preferred alternative so I decided to install that and try it out. I have to say the install and client setup with QR Code was a breeze. I want to use WireGuard as a tunnel into my LAN, so I set it up that way. Now, I'm reading that in order to do this and play nice with my VMs and other docker stuff, I need to define a static route in my router that sends the traffic over to WireGuard. I cannot do this with my Eero mesh router. Am I correct that a static route is needed for my use case? Other than installing another device that can receive the traffic and forward to WireGuard, is there another way? Do I have to move off of OpenVPN, assuming the docker might eventually be pulled from the unraid marketplace? Thanks!

Thanks for the list. I'll be ordering a new card from it. Can installation of a driver at the O/S level affect the BIOS? Seems like any awareness of hardware at the BIOS boot screen would require flashing the BIOS itself? Just for my sanity, is it possible for the Marvell 9215 to cause the flaky behavior I described? I preclear the drive, add it to the array, parity rebuilds it, and then it pretty much immediately flips to a red X. This seems to be the pattern now with drives larger than 4TB.

I need your advice on debugging a problem with my server. I have a Marvell SATA controller to expand the server from 6 to 8 hard drives (I now know that I shouldn't be using such a cheap controller, so I plan to look into that). Here is the hardware report from lspci: # lspci | grep SATA 00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller [AHCI mode] 02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9215 PCIe 2.0 x1 4-port SATA 6 Gb/s Controller (rev 11) I noticed that in the BIOS, the 6 drives connected directly to the motherboard are reported, but the 2 drives connected to the Marvell controller are not reported. Yet, upon boot, fdisk -l reports all 8 drives (plus usb flash and m.2 cache). This seems odd, no? Shouldn't the BIOS see all eight drives? I'm pretty sure that the Marvell controller was working with 4TB drives, but recently, when I attempted to upgrade to an 8TB drive, the drive keeps going offline with a red X. Do we know if this Marvell 9215 SATA controller has trouble with 8TB drives? If this is likely the issue I am having, then I'll be moving quickly to locate and install something better. Is there a SATA controller that is recommended? Or, should I be looking at a SAS HBA like the LSI 9211-8i?? Thanks, Larry

Mine is not running automatically. Is there a way to schedule it?

Assuming you had OpenDNS running and that caused your issue, and it has been turned off, check the DNS servers being used on your clients and servers: cat /etc/resolve.conf on Linux. ipconfig /all on Windows. Maybe the OpenDNS servers are still in the cache? Larry

First, I reset the OpenDNS servers on my router. In my case, I used Google's: 8.8.8.8 and 8.8.4.4. You can also default to the one's provided by your ISP. Then, on the Windows machine where I access the unraid console, I had to flush the DNS servers: ipconfig /flushdns After that, I reinstalled the container and it worked. I have not taken the time to understand why, but I plan to, or if someone already knows, please weigh in.

OK, I figured this out. I had configured OpenDNS at my router to experiment with parental controls and that definitely interfered with this container. Larry