CommandLionInterface

That worked! Thanks!!! I wonder why it worked with that name before I migrated my cache tho 🤔

Hi all, I migrated my cache drive to a larger disk, and the docker vdisk seems to have moved successfully, it exists where I expect it (/mnt/user/system/docker/docker2.img) However, when I go into docker settings and set the vdisk location, the text is red, which I think means the path doesn't exist? It won't let me click apply now, so I can't re-enable docker. Any advice?

Well I think I have a plan. I'm going to see if I can use unix's permission system to force all the contents of my share folder to take on certain permissions. I've been told this is possible.

Hey friends, How do I set the umask for syncthing? My issue is that files I create on my macbook that get synced to my UnRaid are read only over SMB. I have a theory as to why. The default file permissions on Mac (and every unix I've seen except unraid) are 644 for files and 755 for folders. Files on my macbook are created with these permissions, then synced to the server with this permissions, but under the user nobody:users. They are then read only when you access them over SMB. My testing suggests that samba accesses files as whoever you're logged into the share as. So I log in as chuckdries, my user (or guest it shouldn't matter), and I get hit with a read only because I'm merely a member of group. If I manually chown any given file to chuckdries, suddenly that file is writeable over SMB with 644. From this and Unraid's "New Permissions" tool, we conclude that files need 666 or 777 for UnRaid to operate correctly. The default umask for unraid's root user is 0000, so the default permissions are 666 and 777. The solution is to either set my mac to create files with 666 (lol definitely a last resort) or have syncthing transform the permissions correctly, using the ignore permissions flag. Well, if you set the ignore permissions flag, it defaults to... (wait for it) 644. :(. The syncthing documentation says you need to specify the umask if you ignore permissions. How can I specify the umask in this container? Thanks in advance for the help! EDIT: thinking about this more, I'm really surprised it isn't a more common issue. In theory it should afflict every linux and mac syncthing user, unless I'm just an idiot and I'm missing something big. EDIT 2: I see the configuration option about setting a user ID. This would mostly work, as I use the same user to log in from all my devices, but my roommate occasionally uses my server for stuff and I want his user to be able to access and edit everything

Okay, so I ran into a similar issue, found this post when googling, and normally I don't like to resurrect dead posts but I figured I'd round out the answer for future users who may find it helpful. This works. When you start sshd it will generate keys appropriately. The problem is that it's storing them in /etc/ssh/, which isn't preserved across reboots. The solution is to move the newly generated keys to the flash drive, where unraid will copy them into their proper location as part of its booting process. cp /etc/ssh/ssh_host_*key* /boot/config/ssh/ I tested by rebooting and sshing after I did this copy command and it does indeed work, but I didn't test before copying the keys so if unraid auto copies the keys on shutdown or anything like that and my advice is redundant I apologize, but I know for a fact this works.

I'm not normally one to revive old threads but seeing as this is the top result if you google "chrome os unraid" I thought I'd post the answer. Google doesn't provide an ISO for chrome OS, but the chromium project provides chromium OS images for download. They're similar, chrome os is based on chromium os. https://www.chromium.org/chromium-os https://www.chromium.org/chromium-os/how-tos-and-troubleshooting/running-chromeos-image-under-virtual-machines

Well the only thing is that if you pass through whatever video device runs the console, you won't be able to see the console . If you pass through your keyboard, you won't be able to type in the console. It won't cause problems on your guest VM, but good luck typing in the console. Your assumption is sort of correct. So if you want to drive two different displays with hardware accelerated performance, you'll need two different video cards plugged into two different displays. With this setup, you'll also want two keyboards, two mice, etc. or a physical KVM switch. However, there's a trick. VM's don't require video cards. KVM can emulate a video card and show the output over VNC in a web browser. So what I do is I connect both screens to my 1070 which is on my windows VM, then I start a linux VM and use VNC graphics. I connect a native windows VNC client instead of using a web browser and make the client full screen on one of my screens, and voila! linux and windows running side by side on two different screens, you can seamlessly drag the mouse between them and type wherever you click!

Idk about OP, but my plan is to build a raspberry pi with some buttons into a sort of physical KVM switch. I pass all of my IO and my only video output through to my VMs, so I would have my little raspi ssh into the server and start or stop my VMs. Command line! I noticed in the log section of the webui it logs a big long command with a bunch of arguments that encase everything defined in the XML, would these shorter virsh commands have any downsides? If I use the commands, would it pull the system "out of sync" with the web UI?

If those commands really are all you need, you can either make little scripts, store them on your flash drive, then set your run script to automatically move them to your home folder, or you can try setting a shell alias. You'd put a line in your run script to append a a line to either your .bashrc or .bash_profile (or .profile? I'm a little rusty) google the bash alias thing because I'm not sure what the restrictions are on that

So while I was troubleshooting a few unrelated issues I ended up totally screwing up my windows install and replacing it with a fresh image, and it works fine now. Seems like it actually was just a windows driver issue. None of the drivers I downloaded from my motherboard mfgs. website worked, but when I loaded up a fresh install it recognized it immediately after installing the virtio drivers. ¯\_(?)_/¯

Hi guys, Back in 6.2, passing the onboad HD Audio PCI device through to VMs stopped working. Devs provided a workaround in adding this line to append line in the flash drive: modprobe.blacklist=i2c_i801,i2c_smbus This worked for a while, but lately it has not been working. I can see the HD Audio device in Windows Device Manager, but it says "This device cannot start. (Code 10)." I know it's not a driver issue, as the driver environment in my machine has not changed. In fact, it feels like audio will switch between working and not working when I move or open my computer . The VM log says "no available reset mechanism," but it's said that before while the audio does work, and it also says that for the USB controller which works. I'm on the 6.3 rc9 but I don't think it's related to the preview build, as I have experienced the same sort of flakiness on the release builds as well. Any ideas? Here's my XML <domain type='kvm' id='1'> <name>Windows 10</name> <uuid>fbaf2590-f88d-466b-a4a3-e381d683f558</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>6</vcpu> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <vcpupin vcpu='2' cpuset='2'/> <vcpupin vcpu='3' cpuset='4'/> <vcpupin vcpu='4' cpuset='5'/> <vcpupin vcpu='5' cpuset='6'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/fbaf2590-f88d-466b-a4a3-e381d683f558_VARS-pure-efi.fd</nvram> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='3' threads='2'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/nvme0n1'/> <backingStore/> <target dev='hdc' bus='virtio'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/vdisks2/Windows 10/Windows 10/vdisk2.img'/> <backingStore/> <target dev='hdd' bus='virtio'/> <alias name='virtio-disk3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <controller type='usb' index='0' model='nec-xhci'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:45:34:46'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/0'/> <target port='0'/> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/0'> <source path='/dev/pts/0'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-1-Windows 10/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='mouse' bus='ps2'> <alias name='input0'/> </input> <input type='keyboard' bus='ps2'> <alias name='input1'/> </input> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/user/install/drivers/vbios.dump'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x00' slot='0x1f' function='0x3'/> </source> <alias name='hostdev2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x00' slot='0x14' function='0x0'/> </source> <alias name='hostdev3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </source> <alias name='hostdev4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </hostdev> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> </memballoon> </devices> <seclabel type='none' model='none'/> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+100</label> <imagelabel>+0:+100</imagelabel> </seclabel> </domain> Here's my lspci IOMMU group 0 00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM Registers [8086:1918] (rev 07) IOMMU group 1 00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller (x16) [8086:1901] (rev 07) IOMMU group 2 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller [8086:a12f] (rev 31) IOMMU group 3 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-H CSME HECI #1 [8086:a13a] (rev 31) IOMMU group 4 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] [8086:a102] (rev 31) IOMMU group 5 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express Root Port #5 [8086:a114] (rev f1) IOMMU group 6 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express Root Port #9 [8086:a118] (rev f1) IOMMU group 7 00:1d.2 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express Root Port #11 [8086:a11a] (rev f1) IOMMU group 8 00:1d.3 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express Root Port #12 [8086:a11b] (rev f1) IOMMU group 9 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-H LPC Controller [8086:a14a] (rev 31) 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-H PMC [8086:a121] (rev 31) 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio [8086:a170] (rev 31) 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-H SMBus [8086:a123] (rev 31) IOMMU group 10 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (2) I219-LM [8086:15b7] (rev 31) IOMMU group 11 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1070] [10de:1b81] (rev a1) 01:00.1 Audio device [0403]: NVIDIA Corporation GP104 High Definition Audio Controller [10de:10f0] (rev a1) IOMMU group 12 02:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller [1b21:1242] IOMMU group 13 03:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM951/PM951 [144d:a802] (rev 01) IOMMU group 14 04:00.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge [1b21:1080] (rev 04) 05:01.0 USB controller [0c03]: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller [1106:3038] (rev 62) 05:01.1 USB controller [0c03]: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller [1106:3038] (rev 62) 05:01.2 USB controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 65) 05:01.3 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev 46) IOMMU group 15 06:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller [1b21:1242] Here's my VM Log ErrorWarningSystemArrayLogin 2017-01-28 01:12:19.028+0000: starting up libvirt version: 2.4.0, qemu version: 2.7.0, hostname: chuckserve LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/ QEMU_AUDIO_DRV=none /usr/local/sbin/qemu -name 'guest=Windows 10,debug-threads=on' -S -object 'secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-Windows 10/master-key.aes' -machine pc-i440fx-2.5,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=none -drive file=/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/etc/libvirt/qemu/nvram/fbaf2590-f88d-466b-a4a3-e381d683f558_VARS-pure-efi.fd,if=pflash,format=raw,unit=1 -m 8192 -realtime mlock=off -smp 6,sockets=1,cores=3,threads=2 -uuid fbaf2590-f88d-466b-a4a3-e381d683f558 -display none -no-user-config -nodefaults -chardev 'socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-Windows 10/monitor.sock,server,nowait' -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-hpet -no-shutdown -boot strict=on -device nec-s/vbios.dump -device vfio-pci,host=01:00.1,id=hostdev1,bus=pci.0,addr=0x6 -device vfio-pci,host=00:1f.3,id=hostdev2,bus=pci.0,addr=0x8 -device vfio-pci,host=00:14.0,id=hostdev3,bus=pci.0,addr=0x9 -device vfio-pci,host=06:00.0,id=hostdev4,bus=pci.0,addr=0xa -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xb -msg timestamp=on Domain id=1 is tainted: high-privileges Domain id=1 is tainted: host-cpu char device redirected to /dev/pts/0 (label charserial0) 2017-01-28T01:12:22.454449Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control 2017-01-28T01:12:22.468100Z qemu-system-x86_64: vfio: Cannot reset device 0000:00:14.0, no available reset mechanism. 2017-01-28T01:12:22.468138Z qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no available reset mechanism. 2017-01-28T01:12:24.558039Z qemu-system-x86_64: vfio: Cannot reset device 0000:00:14.0, no available reset mechanism. 2017-01-28T01:12:24.558145Z qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no available reset mechanism. ACS override does not appear to make a difference at all.

Unless you have evidence that this doesn't happen when you run the latest stable I don't know how you can support the idea that it is a prerelease bug. If you don't have this evidence I will move the thread to General Support. *edit* Please don't repost it. I can move it. Thank you. The only evidence I can offer is that this combination of docker containers and VM has lived happily together for months on the stable release. That being said, I've also had the RC since December and this just started happening this week, so I can't conclusively point to it being related. Also from reading the other replies it sounds like it may just be a crashplan or docker problem, not an unraid problem. Perhaps a move would be best

Hi guys. I'll jump right into it. I have 16 GB of ram. I run a windows VM that's always on that get's 8 of them. Generally I don't have issues with the other 8 filling up, but lately they have, which crashes my VM when I run out. The thing is, I don't really run much else. I run crashplan and syncthing in docker containers, and usually plex and transmission but I've turned the latter two off since this problem started. My VM always crashes when crashplan is running a backup. Even after the VM has been killed, my ram usage hovers above 50%. If I stop all of my docker containers, including crashplan, my ram usage still stays where it was after the VM was killed. I have observed this behavior when I know for a fact nothing should be accessing my shares or doing anything else. With no containers and no VMs running, and none of the clients on my network accessing the shares, unraid should just sit there and do nothing, but memory usage stays where it was when it crashed my VM. How can I go about diagnosing this? I get a feeling it's a prerelease bug but I don't know how to find more information to determine if it is or isn't more conclusively. If it's not I'll repost this to a different sectiion. (i'm getting my ram usage information from the unraid webui dashboard tab, lmk what else I can do to get more detailed memory usage info)

I pass through my USB controller, it works fine with my vive. Also get a vive! Room scale is INSANE!

My disk utility can't erase the virtual disk. It shows up as "Apple read/write media," Clicking erase defaults to format unknown in the drop down, but no matter what format I choose it says Erase process has failed. Click Done to continue. Further investigation shows the error could not unmount disk, but the disk was never mounted in the first place... Move the image to Desktop and format it from there. I was unable to format my image file on the root drive as well. Thanks! What a weird limitation. Thanks for the heads up.