Leaderboard

Folks, I'm currently maintaining the it87 driver that is now being pulled into your systems, and the current version supports the following chipsets: IT8603E, IT8606E, IT8607E, IT8613E, IT8620E, IT8622E, IT8623E, IT8625E, IT8628E, IT8528E, IT8655E, IT8665E, IT8686E, IT8688E, IT8689E, IT8695E, IT8705F, IT8712F, IT8716F, IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8732F, IT8736F, IT8738E, IT8758E, IT8771E, IT8772E, IT8781F, IT8782F, IT8783E/F, IT8786E, IT8790E, IT8792E, Sis950. If you are have any of these chipsets, then you don't need to specify the "force_id" option any further. If you do find you need it please contact me and I'll look at adding any missing chipsets, but it will depend on what details I can find. Unfortunately, for some motherboards, which have multiple chipsets on board, you will need to add the option "ignore_resource_conflict=1" option, in place of the option "acpi_enforce_resources=lax" during the modprobe command, e.g. for similar reasons, although it only affects the it87 module not others. Good luck with the use of this module that various people have been improving over the years.

I have started to look at creating a PR for this requirement. Also will show missing devices.

Did a reboot fix it and allow you to boot the VM again? With USB I agree things can be finnicky, a slightly more surefire system (and one that supports hotplug) is finding a 'group' of USB ports on your unRAID machine that can be passed through as a USB controller. Those ports will become unavailable to unRAID or other things on your server, but will in ideal circumstances, function as regular hotpluggable USB ports to the VM. I highly recommend considering copying the 'xml' (you don't need to use XML for most VM config tasks) at each stage as you're working through making the VM. It makes it much easier to revert to something that did work. Furthermore, as you're figuring this out, copying the vdisk image file for your VM at various stages is useful as well. It's a snapshot of the computer essentially and makes trying something out hassle free as you can always restore the working image. This is actually one of the reasons I *really* like the VM system (once it works, passing stuff through is always going to be a bit of trial and error), snapshotting and quickly switching through images can be helpful if you're trying things liable to break an OS, or if you're developing something for a specific config. As mentioned by others, passing through an iGPU isn't as trivial as it you'd think due to how IOMMU assignments get sliced up and parted out so to speak. That's why a supported dGPU is often easier to make work in a VM.

I've had two VMs working for years through all versions of Unraid since VMs were introduced without prob;ems. One is using a passed through GPU that took maybe an hour to configure. It does work and can be done. Many Unraid users have working VMs with passed through GPUs. If you want some help post your diagnostics file and explain what you are doing and we will give you some help. If all you want to do is complain, then maybe Unraid isn't going to work for you.

Happy to help and Glad you got it working you have a good weekend now too

What output do you get if you hover over the virsh error? The port number is only used if you enable connect as serial via the slider which is required for map Conbee II correctly above 6.9.2

That plex container is supported on the Plex forums.

It is.

It looks like your last SMART extended test failed which suggests the disk needs replacing. You could try running it again to confirm (but disable spindown on the drive before starting the test).

How much RAM do you have on the server? You need a minimum of 4GB to successfully update via the GUI. If you have less than that you will need to use the Manual upgrade process as described in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

Forgot to update the solution which worked for me. Maybe it's of some help for others. I bought a JMicron Technology Corp. JMB58x AHCI SATA controller card and this solved all issues I had.

genau, einfach ignorieren ...

If you cannot get at least one of the missing drives working a new config is the only option.

Hatte ich nach langer Suche befürchtet. Danke!

Thank you very much, I didn't remember this.

That fixed my issue. Thank you so much!

Create a new Ghostfolio container Variable TZ and leave it blank to get it to run .

For Terraria you have to set the version in the template manually and it will download it after the next start: Don‘t forget that my containers work differently and they pull the updates on every start/restart but since Terraria has no real API where I can pull the latest version you have to set it manually.

Kernel 5.19.3 + Mesa drivers from ppa:oibaf/graphics-drivers seems to work with the newest ubuntu LTS at least provisionally. Haven't tested anything heavy but my screen works and apparently I have hw accel. If you're trying to get this to work, try this. Install Ubuntu in GPU safe mode with just the VNC passed. Get it installed and do the kernel upgrade + mesa drivers. Then pass your GPU + HDMI audio, manually adding in multifunction. As a bonus, edit grub to allow the menu display by default, this will give you an easy road back in to 'recovery' / cli mode if a change breaks your GPU. Can't get both mouse and keyboard passed (either by doing the GUI config, and then re-editing the xml) and ALSO have display show up no idea why? I get conflicts over ports and stuff. Mouse and Keyboard sucessfully passed to other VMs however. It's not a *massive* deal since I don't plan on having physical HID devices connected in the long run. RealVNC server is my choice for control with a passed through GPU. Install it, then "libcanberra-gtk-module" (for some reason it's missing for me after these steps) , then configure it, then disable Wayland. Wayland presents major issues for RealVNC and on the KB+M control front (like synergy / barrier) there isn't a decent option yet. EDIT: Correct Kernel is 5.19.3 sorry for the confusion. https://github.com/pimlie/ubuntu-mainline-kernel.sh is what I used. You're probably better to do it yourself but this worked for me. Uniengine benchmarking works. GPU still shows up as a non specific AMD device in lshw but presents correctly to software I guess? Driver: amdgpu OpenGL 4.6 OS: Ubuntu 22.04.1 LTS Kernel: 5.19.3-051903-generic

The .local domain is a special case. It's a pseudo-top level domain that has been set aside for use by the multicast DNS (mDNS) service, originally developed by Apple as Rendezvous and more recently known as Bonjour, with the aim to provide "zero-configuration networking". Apple released the protocol to the open source community in a series of RFCs and it has been adopted and incorporated into other operating systems, e.g. the avahi daemon provides mDNS for Linux. Instead of querying a centralised DNS server, mDNS requests are multicast to all hosts on the local network and if an mDNS-supporting host recognises its own name it responds with its IP address, using a similar data structure to that used by a conventional DNS server. For a particular container to support mDNS it would need to be built with avahi included.

@cbr600ds2 The plugin has been updated with @doronfix so you should no longer need to update the file manually.

Research suggests something wrong with your network bonding. Edit your network settings or delete / rename config/network.cfg on flash so it will use defaults and reboot

For the record I reported the issue of failing to update to the AUR package maintainer and they fixed it so the AUR got updated and in turn so did the binhex container.

Hi, I would love to migrate to focalboard but the docker won't work. Did anyone managed to make it work? It looks like the docker should connect to a database but there is nothing in the template for that. Thanks!!!

Then you should create the variable. An example from my official Plex, but that should be the same.

The NVIDIA visible devices has gone from the template? or am I missing something? My container failed during updating.. maybe because this option doesn't exist, but I'm not sure. Manually adding the variable worked for me, but figured I should report it..

I've applied a fix for this in the next docker container update.

I had the same error. Make sure '/config/database' is owned by abc:users. In Unraid/Docker tab, click ownCloud icon -> Console Run command: ls -l /config If it doesn't say "... abc users ... database", run command: chown abc:users /config/database ..that solved it for me.

@dlandon has created a Python 2 plugin, so WOL is now no longer being deprecated

Appreciated, this was no easy task since I had zero understanding of how to compile a kernel now I know a little bit... I was also looking for a way to upgrade my drivers a little bit faster and also to add custom kernel modules the 'easy' way (I totally understand that linuxserver can't build a new image for each new driver version...) If you got any suggestions feel free to contact me. Btw: I uploaded the container already but it will take a bit to update in the CA App.

Here is a temporary solution until limetech has implemented this feature:

It's not as bad as you are thinking it is. You only need to add user names for those wanting access to Private shares or wanting write access to Secure shares, everyone else will have "guest" access (by "guest" I mean not as user name "guest" but anonymous access). Actually it's better NOT to have a user name "guest" because that will confuse AFP when/if you use that (LOL that's another story). Sorry, these are not unRaid-specific issues. Ok, to be exact, you don't have to use your windows login name. You can use any name that's defined on the unRaid side. You just have to make sure that the very first access to any share on the server results in you correctly entering that user name/password in the dialog box. Having done that once, your Windows PC will "remember" those credentials for future access to the same server and you won't have to enter the username/password again. Let me give you an operational example. Let's say your windows PC netbios name is "mypc" and your windows login name is "larry". Further let's say your server netbios name is "tower" and you have a single user defined on unRaid side named "curly". Now you open Network and click on "tower" and a window opens showing all the shares. In this state, if you now click on a "public" share, what happens behind the scenes is windows tries to authenticate with the server as user "mypc\larry". On unRaid side, samba (linux smb protocol module) will check if "larry" exists. In this case no, so samba will check if user "mypc" exists, in this case also no. So samba will now see that "guest" access is enabled for the server, so it will reply to Windows with "success" but on the samba side, will associate any further access with the "nobody" user on the linux side. Meanwhile, Windows stores the fact that it successfully connected with user "mypc\larry" in its own credentials cache. Now, after above, you click on a Private share where the only unRaid user with access is "curly". Samba will see the request to the share as user "larry" and tell Windows that the connection is unauthorized (because larry is not in the list of users for the Private share). Windows sees this and presents you with a username/password dialog box. So you enter "curly" as the user. But now Windows sees that you already have a connection to the server as user "larry" and it DOES NOT ALLOW multiple connections to the same server via different user names. This is a well-known limitation/bug in Windows. Some people get around it, e.g., by connecting to the sever using the IP address in order to fool windows into thinking it's a different server. To get above to work, you would close any windows that might have a previous connection to the first public share, then open a command window and type "net use * /delete". That command closes all current server connections. Now click on your Private share and enter "curly" user name it will work this time. Same scenario, but this time after opening Network and clicking on "tower" you happen to click on a Private share first. You get the dialog box and login as "curly" and everything works. Now you click on a Public share and it still works (because on unRaid side all user names are accepted for Public shares). So you see the behavior can be quite different and confusing depending on what you click on after clicking on the server. Now you also know why it's easier to just use the same user names.