lotetreemedia

Pretty much what everyone said above. But you can periodically update all of your Docker containers through unRAID's GUI. Go to the Docker tab Click on Check For Updates Any containers that have updates available will show Update Ready under Version Click on Update All

Had to grab myself the water bottle on March 20th. Was sad the larger one was out of stock Never the less can't wait for it to arrive!

Just add a sheduled task, insert "system" in the "run as" field and point the task to a batch file with the simple command net use z: /delete and net use z: \\servername\sharedfolder /user:username password Then select "run at system startup" (or similar, I do not have an English version) and you are done. Taken from stackoverflow http:// https://stackoverflow.com/questions/182750/map-a-network-drive-to-be-used-by-a-service#comment25569654_4763324 Sent from my iPhone using Tapatalk

You are a security nightmare Ofcourse you can set a username and password for the UI. It's the root user. Go to Users > Root Set the password for that account. Next time you login:

I think you're on to something with regards to the drivers. They may not be optimized just yet. might be worth raising with @linuxserver.io possibly?

Wish I could help test this but haven't got any kidneys left to sell for a 2080! have you tried running: top in the terminal to see running processes with the 1070 vs the 2080? wondering if there's extra resources being taken up by qemu or the like with the RTX popped in.

Might not be the case anymore:

Seems the context is here: Why did you have to do all the above steps to make it work?

according to this post looks like the first few messages are normal. the last line i think just means its been shutdown. to help Please post your diagnostics: Tools -> Diagnostics

Just a couple of checks. Bios up to date GPU is present in the BIOS If that’s all good Use GPU-Z to dump your VBIOS as opposed to downloading it off techpowerup. There was someone a few days ago that had the same problem and dumping his VBIOS off GPU-z worked and not the techpowerup one. Sent from my iPhone using Tapatalk

There’s only cosmetic limitations. The watermark, not being able to change wallpaper from within personalisation(you can still right click in explorer and set it though) and some messages in settings. Everything else is the same even updates. Not sure of the legality of it but I don’t think MS is too fussed about it compared to people using Windows for commercial purposes. Sent from my iPhone using Tapatalk

Just buy one from kinguin https://www.kinguin.net/?r=34615 Much cheaper on there Sent from my iPhone using Tapatalk

Ah I see Sent from my iPhone using Tapatalk

I don’t think number 4 is meant to happen. Your GFX card is not meant to have any output until you start the VM. Have you enabled iGPU in the motherboard? That basically tells your motherboard to use intels GPU. Plug in something to the onboard HDMI port and make sure your BIOS/ unRAID boot is coming from there effectively leaving your 1060 available for your VM. I think what’s happening is that your VM can’t be passed the GPU as it’s being used by unRAID. Not sure, but I think this might be the case perhaps? Sent from my iPhone using Tapatalk

If there any way to change my forum display name / handle? Sent from my iPhone using Tapatalk

It's your data chief Full disclosure, All of this is uncharted territory (for me personally) and I'd have zero liability if something went wrong. If I were you id test, test, and then test. try doing a proof of concept. Use the cloudberry trial to backup some small data to minio on your LAN. Change the data (Add some files , remove some files, update some files)without doing a backup Take that machine to your friend place, setup port forwarding to minio and duckDNS. Update your cloudberry container to point to duckDNS. Run the update task again on your source machine. Expected behavior should be: Added files are now present in the backup and it didn't re-run the entire backup. updated files are updated in the backup. you're able to restore the files you deleted. Hopefully your friend isn't located on the other side of the pond!

Have you got compression turned on on your FreeNAS pool? I think it's on by default

I've been having some of these issue lately. Just so eliminate simple solutions first. Is the VBIOS one that you've downloaded or edited yourself? Is your card one of those crypto mining ones with no HDMI out? Does the video for the VM work when primary card is set to VNC? If you plug in a monitor to the GPU does it show up?

You can also download the full OS and use the trial for 30 days Sent from my iPhone using Tapatalk

Am i missing something? If you mark the share as private and don't Export it how will they be able to access your files? Here's me creating a share Name = maxse Export = no Security = Private If they browse to your server and you do have some Exported shares they will see this. Not much they can do with that unless you name one of your shares "XxX HardCore...." then they might have some suspicion that your storing some non PG stuff. If by some miracle they figure out your share name and try to browse to it . If you had your share as Export = yes (hidden) They would still get a prompt asking for credentials. And besides, you don't have to create a share anyway for Minio. just manually create a folder under /mnt/user and pass that to the container as the location to store the data.

Define browse . GUI ? Via a share? Taking the drive out and plugging it In somewhere? Sent from my iPhone using Tapatalk

2019-02-23T14:58:23.694736Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0) 2019-02-23T14:58:33.950288Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.950474Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.950687Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.950824Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.950957Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.951096Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.951355Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.951495Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.953427Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.957654Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.957876Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.958020Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.958177Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.958323Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.959068Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.959214Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.961088Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.965271Z qemu-system-x86_64: vhost_region_add_section:Section rounded to c0000000 prior to previous c0000030 2019-02-23T14:58:33.972969Z qemu-system-x86_64: VFIO_MAP_DMA: -14 2019-02-23T14:58:33.972975Z qemu-system-x86_64: vfio_dma_map(0x1528a63b1140, 0x800000000000, 0x2000000, 0x15268de00000) = -14 (Bad address) Tried recreating the VM and same problem. Clicking on logs for the VM shows this

Ah yes this might work actually

Glad you got it sorted

Updated to 6.6.7 this morning. Everything seems dandy bar one VM issue. Windows 10 VM with a GTX1070 passed through. tried to start the VM after update and I couldn't RDP into it. Switched the Graphics card to VNC / QXL to see what was happening and it booted just fine. I noticed however that the network adapter was replaced with another one Red Hat .... #2 - So I changed the IP of the new adapter to the old static IP and I could RDP back into it just fine. However If i switch back to the 1070 I can't RDP / ping the VM. Any ideas? limnas-diagnostics-20190223-1408.zip