Leaderboard

Note: this thread is locked. Any questions, please post in the unRaid FAQ Feedback Thread. Community Applications - Application Policies Community Applications has one fundamental goal: Ensuring that the end-user experience with the various add-ons to your server is consistent and trouble free. The application lists contained within CA are moderated and vetted. Every attempt is made to ensure that only safe and compatible applications are present. As the unRaid community gets larger, and more applications become available within Community Applications, the following should be noted: All applications are subject to approval for inclusion. Closed source plugins are not accepted into CA. (Note that a plugin may include closed-source binaries which in certain circumstances do not violate this rule - Moderator's discretion). In certain exceptional cases an exemption to this rule may be granted. Closed source applications within an docker application are generally not accepted within CA unless they are from a reputable source or are a well known application (eg: Crashplan, Plex et al). In other words, an application created by the template maintainer MUST be open source and subject to code examination. All GitHub repositories / dockerHub repositories must have 2 Factor Authentication enabled, and an acknowledgement of this must be given to the authors/maintainers of Community Applications or Limetech. Plugins which are better suited as a docker application are not eligible for inclusion in CA. "Proof Of Concept" applications are generally not accepted into CA. If it is accepted into CA, then such applications must include an appropriate notice within its description. Any application that contains malicious software or intent is subject to immediate removal with no notification being given. This also includes any other software included within the application such as crypto mining unless the application itself is for crypto mining. No Exceptions. Bugs within applications can (and do) happen. This is outside of the control of the moderators of CA. Depending upon the circumstances, the application may be subject to moderation due to the bug. This moderation may be mild or in the cases where the bug could cause data-loss severe resulting in the possible blacklisting of the application. In most cases, the author is given time to rectify the bug before moderation happens. Minor issues with any application will tend to not have any moderation applied. As a general rule, it is recommended to always keep your applications (especially plugins and unRaid itself) up to date. In the case of egregious software errors, the moderators of CA will err on the side of the user instead of the side of the author. Plugins may on occasion (this is an exception, rather than the rule) have problems / bugs when run on a release candidate of unRaid. More leeway is given to authors of the plugin in this situation than if the issue occurs on a stable release of unRaid. Any application listed within CA is subject to at any time various means of moderation. This includes but is not limited to fixing template errors, assigning minimum / maximum versions of unRaid the application is compatible with, notifying users of any issues with their installed applications via the Fix Common Problems plugin, deprecating an abandoned application,etc. Notification to the template maintainers may or may not be given. So called abandoned applications (where the author / maintainer) has completely abandoned support for the application may or may not be removed from CA. This primarily depends upon whether or not the application works for its designed purpose. However, should another template be published within CA that supersedes the abandoned template, then the abandoned one may be removed with no notice being given. Any application template not meeting certain minimum standards results in automatic removal of that application until such time as the template is revised to meet those standards. (As an example, all applications must include a reasonable description.) In certain circumstances, it may be more appropriate to utilize "branches" in templates than to submit multiple templates. This is discretionary of the moderators. See here. Any violation of the security policies enforced by CA and the associated application feed results in automatic blacklisting of an author's entire template repository. No warnings and no exceptions. The case of any submitted application which refers to the exact same dockerHub repository as an existing application will not be accepted. In certain circumstances though the pre-existing application template may be removed and the new one accepted in its place - Moderator's discretion. All templates within a specific repository must have different application names. In case of a conflict within the same repository, one of the templates is automatically removed Donation links are allowed and encouraged but only show up for installed apps and on your "Repository" section in Community Applications. All descriptions, icons etc must not be "offensive" and should adhere to "good taste". Furthermore, animated icons are not allowed. In the situations where there is already a multitude of certain applications available (ie: Plex, nzbGet, Radarr, etc) new submissions of those applications will not be accepted. An exception may however be made if the new submission brings something unique to the application. This is at the discretion of the moderators of CA. A further explanation of the last point is in order (In this example, I am referring to Plex Media Center itself, not the various add-ons available for Plex, eg Plex Connect, plpp, gaps, etc) Utilizing Plex as an example, there are already applications within CA from Binhex, LinuxServer along with the official Plex Container. All of these are extremely well supported and maintained, and fundamentally there is absolutely no difference between any of them. It is extremely unlikely that any new submission of a Plex application will bring any tangible benefits to the unRaid community, and will more than likely only cause confusion for the end-user as to "which one do I install?" The end-user experience is of utmost importance to the authors of Community Applications, it's moderators, and Limetech themselves. This however does NOT mean that no new Plex will be accepted. If a new Plex application is submitted and it does bring something new / unique to the application / container it may be accepted at the moderator's discretion. Should any user wish to run a version of Plex that is not available within CA, there are multiple options available. ( Performing a dockerHub search for the application, having CA manage so-called "private applications", or utilizing the template repository system of unRaid itself. ) See here. The intent here is to not stifle any innovation from any given author, but rather to ensure that the end-user experience remains consistently high. If the circumstances regarding an already present Plex application change ( no longer maintained / supported, or is deemed to be extraneous and not benefiting the unRaid community, etc ) then that existing application may be removed and new submissions for Plex may be accepted. CA does allow installations of deprecated / incompatible applications by visiting it's Settings Page. (Although it is not recommended to do this.) Any plugin or docker application which is classified as being Beta from the author is identified within CA. This classification does not however mean that there will be problems with the application. The ability to install applications that are outside of CA's control (plugin or docker) will never be impeded. (Although it isn't recommended to install any plugin that is not available within CA) All actions taken by a moderator of CA (or via the associated application feed) is publicly viewable either within CA under it's Statistics section, or via a GitHub Repository. In the rare case of a controversial decision taken by the moderators of CA, the decisions are reviewed by a larger select group of trusted unRaid users and the staff members of Limetech. If as a maintainer / author you disagree with any actions taken by the moderators of CA you should bring your concerns in a PM to @Squid. If the decision made by Squid does not satisfy you, then the final decision will be made by @SpencerJ (Note: The moderators of CA @pluginCop and @dockerPolice do not read or reply to any PM) On the other side of the coin, if as a user you feel that some application should be moderated in some way, then feel free to PM @Squid who will then delegate appropriately to one of the moderators of CA. Note: this document may be amended at any time, and any new policies added (or policies changed) will be retroactive to any / all applications within CA. Further note: All download counts listed within CA are based upon dockerHub. In the case of ghcr containers, the stats will be gathered from the dockerHub version instead. If an equivalent dockerHub container does not exist, then no download stats will be listed. Also, not all dockerHub containers have the ability to discern the download counts. To get your apps added to CA, see HERE.

One option - if you can get to the command line, you could type something like this: /usr/local/emhttp/webGui/scripts/notify -e "Your Unraid server is not secured" -s "I found your Unraid on the Internet without a password" -d "You need to secure this before someone hacks you" -i "alert" That will give them a notification on the webgui and send them an email (if they have that configured)

Turn them off? Maybe use the builtin send notification functionality first? Would be nice way to have then generate the popup or email or log it in syslog.

This is a plugin that shows the file and directory activity on the array by disk. This includes read and write activity on the array. Read activity can cause disk spin ups. It is recommended that you have the Dynamix Cache Directories plugin installed and running. The plugin uses inotify to log read and write disk activity. You will need to start File Activity to start the logging. I don't recommend leaving it on all the time. A server with a lot of file activity can fill the log space. You can see which files and directories are being read and written and keeping the disks from spinning down. The file activity is shown by disk, UD disks, and the cache and Pool drives. The 'appdata', 'syslogs', and 'system' shares are excluded. This is not the ultimate answer for disk spin ups, but I used it to find an issue with Windows 10 backing up files every hour. It would write new files on the cache, but constantly modify the older file directory entries causing spin ups on disks. The plugin is installed in the Tools menu under System Information. The preferred way to install the plugin is with CA. Or you can install the plugin by copying the following URL in the install plugin line of unRAID: https://github.com/dlandon/file.activity/raw/master/file.activity.plg

I know they are still very new but I am wondering if anyone has info on the various trx40 boards and their compatability with unraid and hardware pass through, iommu groupings and such. I am currently looking at the asrock trx40 creator, or the msi creator trx. I already have all the other parts for my upgrade including the 3960x, but it seems the mobo is the hardest part to decide on, and find. Leaning toward the asrock because I believe that was a board that level1 had good luck with the iommu grouping in the past, but for the price difference I would also like that 4 x nvme to pcie card.

Thank you all for entering our giveaway! At 1/9/2020 at approximately 11:55 AM Pacific, we hit 100,000 forum members! Entries are now closed, winners have been contacted and prizes have been mailed out. A sincere thank you to you all for being a part of this 100,000 strong community! The Unraid forum is about to hit a major milestone: 100,000 members! As of Christmas time, 2019, we're sitting at approximately 99,000 forum members. To commemorate this awesome community achievement, let's do another giveaway! What's at stake? 90 winners will receive limited-edition Unraid case badges! These 2x2 inch domed, polyurethane server badges will look great on your own home lab (badges not for sale, sorry)! 9 winners will receive an Unraid case badge AND a $25 gift card to the Unraid merch store. 1 Grand Prize Winner: receives a case badge, a $25 gift card AND an Unraid pro license! Pretty sweet huh!? See the linked blog post for pics and additional info! How to Enter: Simply tell us: one thing you like most about Unraid and one thing you'd like to see added to the OS in 2020 That's it! Winners will be drawn at random from the forum entrants here. At our current rate, we will likely hit 100,000 members late January or early February 2020. Follow the Unraid twitter account for periodic forum # updates! Entries will close as soon as we hit 100,000 forum members so don't delay in entering! Good luck. https://unraid.net/blog/unraid-forum-100k-giveaway

TLSv1 is being obsoleted this Spring and TLSv1 and TLSv1.1 should be removed from nginx.conf: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; Major browsers are committed to supporting TLSv1.2 so there should be minimal issues.

To install this release, navigate to Tools/Update OS and select the Next branch. This release fixes an issue with entering encryption passphrase via webGUI. In addition, we updated libvirt and qemu to latest versions where bugs which caused us to revert to previous versions appear to be fixed. For these reasons, I want to have a brief pre-release for wider testing before publishing to stable branch. Bugs: If you discover a bug or other issue in this release, please open a Stable Releases Bug Report. Version 6.8.1-rc1 2020-01-06 Base distro: kernel_firmware: version 20191118_e8a0f4c (with additional Intel BT firmware) libvirt: version 5.10.0 php: version 7.3.13 (CVE-2019-11044 CVE-2019-11045 CVE-2019-11046 CVE-2019-11047 CVE-2019-11049 CVE-2019-11050) qemu: version 4.2.0 samba: version 4.11.4 wireguard-tools: version 1.0.20191226 Linux kernel: version 4.19.93 CONFIG_THUNDERBOLT: Thunderbolt support CONFIG_INTEL_WMI_THUNDERBOLT: Intel WMI thunderbolt force power driver CONFIG_THUNDERBOLT_NET: Networking over Thunderbolt cable oot: Highpoint rr3740a: version v1.19.0_19_04_04 oot: Highpoint r750: version v1.2.11-18_06_26 [restored] oot: wireguard: version 0.0.20191226 Management: add cache-busting params for noVNC url assets fix cryptsetup passphrase truncation network: disable IPv6 for an interface when its settings is "IPv4 only". webgui: Management page: fixed typos in help text webgui: VM settings: fixed Apply button sometimes not working webgui: Dashboard: display CPU load full width when no HT webgui: Docker: show 'up-to-date' when status is unknown webgui: Fixed: handle race condition when updating share access rights in Edit User webgui: Docker: allow to set container port for custom bridge networks webgui: Better support for custom themes (not perfect yet) webgui: Dashboard: adjusted table positioning webgui: Add user name and user description verification webgui: Edit User: fix share access assignments webgui: Management page: remove UPnP conditional setting webgui: Escape shell arg when logging csrf mismatch

Can you add an option to change the background color and the boxes background color?

You are right. The first container runs `runserver 0.0.0.0:8000 --insecure --noreload` (webserver) and the second one `document_consumer --no-inotify --loop-time 60` (consumer) in „Post Arguments“. Both containers have the /consume folder shared. I will update the install instructions with pictures and making it more precise once I find the time. If you stick to smb shares you might omit the `--no-inotify --loop-time 60` . Thanks for the additional configuration variables. We plan to update the template and I will consider these too.

It's also worth noting that FreeBSD bug reports really haven't gotten any official response. The users that made the bug reports are the ones making the progress. Would anyone on your team have connections to get some official eyes on the bug?

If scraping is the issue then running in a vm will not improve things, it's the same application (pms) Sent from my CLT-L09 using Tapatalk

msconfig -> boot -> advanced options -> Number of processors set to 24 (total provided to the VM). Page file -> disabled MSI enabled on: More tweaks to come soon, I'm still reading a ton of posts on reddit and the libvirt manuals, testing and getting some feedback from LatencyMon.

Ahh it is probably the non standard port, if you delete your servers.json file and restart the api, then set the server up as ip:port it should work

not at this time,no, having said that if you are using a decent vpn provider (which i think you are now, pia right?) then the hostname as specified in the remote line in the ovpn file will resolve to multiple ip addresses, each of these ip addresses will be tried randomly on disconnection, so there is some resilience there, let me put it this way, i havent to date (running for several years) had an issue where openvpn fails to reconnect due to all of the vpn servers being offline for a single endpoint.

Just in case people do miss it (and they probably will), the policies regarding CA and the applications contained are now publicly posted. It's more just iterating what myself and @dockerPolice / @pluginCop already do on a daily basis. (And these policies are impartial. If anything, @pluginCop is hardest on me - the guy's just got it in for me for some reason )

I would just keep using SMB and windows for it. Sweet and simple

Open a github issue for a feature request and we'll add it when we get to it

One option might be to start the array without parity2 assigned and tick the parity is valid box. That way you get a protected array as early as possible (assuming parity1 IS valid). You can then stop the array; assign parity2; start the array to build the contents of parity2. You will still want to carry out a parity check afterwards to make sure parity1 WAS valid. The alternative is to make no assumptions about parity and not tick the parity is valid box so that both parity1 and parity2 get rebuilt in parallel when you start the array.

I've updated UD and added a 'Read Only' switch for physical drives so you can mount the drive read only. This can be helpful if you have an array drive you'd like to mount and look at but don't wan't anything written to the disk that would break parity.

No drivers required, those adapters are transparent to the OS, though there could always be problem with it, or the NVMe device, it's failing to initialize, some times they have issues with power states, you can try this: Main GUI page click on the flash drive, scroll down to "syslinux configuration" and add this to your default boot option, after "append" nvme_core.default_ps_max_latency_us=0 Then reboot, but doubt it will help in this case, next step would be to try the NVMe device on a different adapter or onboard.

@ich777Sure, I´ll help explain. Server: Zabbix server is the central process of Zabbix software. The server performs the polling and trapping of data, it calculates triggers, sends notifications to users. It is the central component to which Zabbix agents and proxies report data on availability and integrity of systems. The server can itself remotely check networked services (such as web servers and mail servers) using simple service checks. Web: Zabbix web interface is a part of Zabbix software. It is used to manage resources under monitoring and view monitoring statistics. Agent: Zabbix agent is deployed on a monitoring target to actively monitor local resources and applications (hard drives, memory, processor statistics etc). So all three is a part of getting it up´n running.

The config transfer to move to a new flash drive is contingent on a paid license, the trial version requires setting things up again, for the obvious reasons. It's not obvious from your posts whether you have a paid license yet, so I wanted to point that out. Also, since the flash hardware GUID is linked with the license, when you change flash drives the license must be reissued to activate the new drive and deactivate the old flash. This is an automated process through limetech's servers, with a 1 year restriction. If you need to change flash drives sooner than 1 year, you will need to contact them and ask for a manual reissue.

Well you've really sent me down the rabbit hole Tagging @limetech for visibility Not only should we disable TLSv1 and 1.1, we should enable 1.3. Lots of good info here: https://en.wikipedia.org/wiki/Transport_Layer_Security TLSv1.0 and 1.1 have multiple vulns: https://www.globalsign.com/en/blog/disable-tls-10-and-all-ssl-versions/ https://tools.ietf.org/id/draft-moriarty-tls-oldversions-diediedie-00.html TLSv1.2 is good, with significant availability: https://qsportal.atlassian.net/wiki/spaces/DOC/pages/3571715/TLSv1.2+Browser+Compatibility TLSv1.3 is best, with security and performance improvements over 1.2 (this should make the webgui a little faster in modern browsers that support it): https://casecurity.org/2018/04/10/tls-1-3-includes-improvements-to-security-and-performance/ According to this page: https://qsportal.atlassian.net/wiki/spaces/DOC/pages/3571715/TLSv1.2+Browser+Compatibility TLSv1.2 has been enabled by default in most browsers for quite a while now: Chrome since version 38 (2014) Firefox since version 27 (2014) Safari since version 7 on OSX 10.9 (2013) IE since version 11 (2013) Edge (all versions) Android since Lollipop (2014) iOS since iOS 5 (2011?) So the risk of dropping TLSv1 and 1.1 seems very small. If people really want to keep using their obsolete clients and don't care about the security issues, I see two options: add an option to the webgui to enable v1 and/or v1.1 (if we think a lot of people will need this) or provide a sed command that people could manually add to their go script that adds TLSv1 and/or TLSv1.1 to the nginx.conf. Speaking of which, users who want to secure their systems today can use a good text editor (such as Notepad++, not Notepad) to edit the /config/go script in their "flash" share. Add these lines to the top of the file (above the reference to emhttp): # disable TLSv1 and TLSv1.1, enable TLSv1.2 and TLSv1.3 # see https://forums.unraid.net/topic/86949-tlsv1-is-being-obsoleted-this-spring/ # Note: this is not needed in Unraid 6.8.2 and higher sed -i 's/TLSv1 TLSv1.1 TLSv1.2/TLSv1.2 TLSv1.3/' /etc/nginx/nginx.conf Before rebooting, if you type this command: grep ssl_protocols /etc/nginx/nginx.conf you should see: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; After rebooting with the updated go script, that same command should return: ssl_protocols TLSv1.2 TLSv1.3; To undo this change, delete those lines from the go script and reboot.

Hi Shane, I have been running Samsung SSD Drives for 4+ years as part of a cache pool and recently just added my fourth Samsung SSD to the pool without any issues. Prior to that I had used a single spinner for the cache drive. I also use a Samsung SSD Pro Drive through unassigned devices for my Plex transcodes and for VM's. Transcoding creates a lot of writes to a drive and can burn through a warranty & lifespan pretty quickly on the lower grade SSD models. Perhaps others have had issues with Samsung SSD's, but for myself I have not. I've had an Unraid server running for 8+/- years now and have always funneled everything through the cache drives before dumping onto the storage drives. As a result I feel I get a longer lifespan out of my drives because they don't have to spin up every time something is added ... a few of my old drives have 60,000+ hours and are still chugging along. I've been using the forum for years without posting to search and solve any dilemmas that I got myself in to, so this is the first time posting on the forum. I thought I would quickly give you a reply since I have a similar setup to what you are planning to do. Have fun setting up your new server!

Well, been playing with this 36 bay unit. really great holding 30 hard drives in 1 box now. It's an Isilon (Dell EMC) 36 bay NL400 chassis.. about $300 on Ebay as we speak. Great deal.. except.. it's loud AF. A real jet engine. The 3 central fans are horrible. I've replaced them with some spare 80mm fans, but .. now its causing the drives to overheat. Guessing I need some good high pressure (and silent) 80mm intake fans. I've put my H55 liquid cooler on 1 CPU for testing.. works, but i can't put the top on the unit since there's no space to mount this in a 2U area (the other bottom half is taken by the rear drive bays.. This is the ebay ad: https://www.ebay.ca/itm/Supermicro-36-bay-4U-Server-Storage-Chassis-Extended-ATX-Ethernet-Freenas/202805514541?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 I may mount a 200mm fan on the top of my rack to exhaust the heat. I've ghetto mounted 3x 120mm fans on the front of the unit to draw air into it, helped bring it down by 15 degrees, but still not enough. Expansion backplane works great with my LSI2008!

When this bug is sorted I'll produce a 6.9 release which is exactly same as 6.8 except for latest stable kernel (and omission of out-of-tree drivers which don't build with this kernel):

I have not managed to get it sorted yet, but you could try this. If you have any luck post your results. Good luck

ok, below is the xml of one of your passed through devices. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x07' slot='0x00' function='0x3'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> the address type is inserted automatically by unraid and its generating a seperate bus for every hostdev. Looking at the error log I assume pfsense does not correctly allocate those. You can try the following which worked for me: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x07' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x07' slot='0x00' function='0x2'/> </source> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x2'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x07' slot='0x00' function='0x3'/> </source> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x3'/> </hostdev> I just changed the bus for the following entries to "0x01" (value of the first entry, which I assume is allocated correctly in pfsense) and additionally increased the function value for every entry. Afterwards I reset pfsense from the command line and after rebooting all passed through network cards were available. I hope this helps.

Disk appears to be failing, you can use ddrescue to clone it to a new disk then run reiserfsck.

Same happened to me... Do a diff on the files after you make changes and you can see that a lot more changes than what space invader says in his video. I tried to add a graphics card and wow...if you're new to this stuff you definitely started in about the hardest spot. The diff between XMLs did help though as you can see what is actually changing unexpectedly. Good luck.

I had a chance to play around with GPU passthrough to a VM today. I'm using a 3970X, an Asus Zenith II Extreme, and a GTX 970. Everything with setup went smooth. I followed Spaceinvader One’s latest video for advanced GPU passthrough. I'm using a dumped vBIOS rom file for the GTX 970. I tested the system using the Shadow of the Tomb Raider Benchmark. Here are some screenshots of the results. I'm getting roughly 90% of bare metal performance in the CPU Game metrics.

I finally got my 3970X and I've begun testing with an Asus Zenith II Extreme and an Aorus TRX40 Master. My main interests were in the rear panel USB controllers and M.2 connections to the CPU. My GPUs have water blocks on them and it will be a while before I'm able to test passthrough using them. Zenith II Extreme: Surprisingly, the Zenith II Extreme only offers one dedicated M.2 connection to the CPU (M.2_1). M.2_2 connects directly to the CPU, but it shares 4 lanes of bandwidth with PCIE_X16_4, which makes it unusable for me because I will need all 8 lanes of that slot for an HBA. USB Controllers: 03:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller 22:00.0 USB controller: ASMedia Technology Inc. Device 3242 24:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller 49:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller 49:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller The ports circled in red are connected to 49:00.3, the ports circled in blue are connected to 24:00.3, the ports circled in yellow are connected to 49:00.1, the ports circled in purple are connected to 03:00.3, and the port circled in pink is connected to 22:00.0. The ASMedia controller and the AMD Starship controllers are in their own IOMMU group and can be reset. The AMD Matisse controllers are in the same IOMMU group and only one of them can be reset. PCI Devices and IOMMU Groups: IOMMU group 0: [1022:1482] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 1: [1022:1483] 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 2: [1022:1482] 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 3: [1022:1482] 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 4: [1022:1482] 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 5: [1022:1482] 00:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 6: [1022:1482] 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 7: [1022:1484] 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 8: [1022:1482] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 9: [1022:1484] 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 10: [1022:790b] 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61) [1022:790e] 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) IOMMU group 11: [1022:1490] 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 0 [1022:1491] 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 1 [1022:1492] 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 2 [1022:1493] 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 3 [1022:1494] 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 4 [1022:1495] 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 5 [1022:1496] 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 6 [1022:1497] 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 7 IOMMU group 12: [10de:1380] 01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2) [10de:0fbc] 01:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1) IOMMU group 13: [1022:148a] 02:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 14: [1022:1485] 03:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP IOMMU group 15: [1022:148c] 03:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller IOMMU group 16: [1022:1482] 20:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 17: [1022:1482] 20:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 18: [1022:1482] 20:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 19: [1022:1483] 20:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 20: [1022:1483] 20:03.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 21: [1022:1482] 20:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 22: [1022:1482] 20:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 23: [1022:1482] 20:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 24: [1022:1484] 20:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 25: [1022:1482] 20:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 26: [1022:1484] 20:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 27: [144d:a804] 21:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961 IOMMU group 28: [1b21:3242] 22:00.0 USB controller: ASMedia Technology Inc. Device 3242 IOMMU group 29: [1022:148a] 23:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 30: [1022:1485] 24:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP IOMMU group 31: [1022:1486] 24:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP IOMMU group 32: [1022:148c] 24:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller IOMMU group 33: [1022:1487] 24:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller IOMMU group 34: [1022:1482] 40:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 35: [1022:1483] 40:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 36: [1022:1482] 40:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 37: [1022:1482] 40:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 38: [1022:1482] 40:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 39: [1022:1482] 40:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 40: [1022:1482] 40:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 41: [1022:1484] 40:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 42: [1022:1482] 40:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 43: [1022:1484] 40:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 44: [1022:57ad] 41:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57ad IOMMU group 45: [1022:57a3] 42:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 46: [1022:57a3] 42:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 47: [1022:57a3] 42:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 48: [1022:57a3] 42:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 49: [1022:57a3] 42:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 50: [1022:57a3] 42:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 51: [1022:57a4] 42:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4 [1022:1485] 49:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:149c] 49:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] 49:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller IOMMU group 52: [1022:57a4] 42:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4 [1022:7901] 4a:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) IOMMU group 53: [1022:57a4] 42:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4 [1022:7901] 4b:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) IOMMU group 54: [144d:a808] 43:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 IOMMU group 55: [1d6a:07b1] 44:00.0 Ethernet controller: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] (rev 02) IOMMU group 56: [1b21:0612] 45:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) IOMMU group 57: [1b21:0612] 46:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) IOMMU group 58: [8086:1539] 47:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) IOMMU group 59: [8086:2723] 48:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) IOMMU group 60: [1022:148a] 4c:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 61: [1022:1485] 4d:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP IOMMU group 62: [1022:1482] 60:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 63: [1022:1482] 60:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 64: [1022:1482] 60:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 65: [1022:1482] 60:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 66: [1022:1482] 60:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 67: [1022:1482] 60:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 68: [1022:1484] 60:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 69: [1022:1482] 60:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 70: [1022:1484] 60:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 71: [1022:148a] 61:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 72: [1022:1485] 62:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP TRX40 Aorus Master: This board is much more practical for me. It offers the same VRM configuration as Gigabyte's top end boards and two M.2 drives from the CPU, which seems to be the most possible without reallocating lanes dedicated to the expansion slots. USB Controllers: 03:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller 23:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller 47:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller 47:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller The ports circled in red are connected to 47:00.1, the ports circled in blue are connected to 23:00.3, and the ports circled in yellow are connected to 03:00.3. The AMD Starship controllers are in their own IOMMU group and can be reset. The AMD Matisse controllers are in the same IOMMU group and only one of them can be reset. PCI Devices and IOMMU Groups: IOMMU group 0: [1022:1482] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 1: [1022:1483] 00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 2: [1022:1482] 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 3: [1022:1482] 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 4: [1022:1482] 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 5: [1022:1482] 00:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 6: [1022:1482] 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 7: [1022:1484] 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 8: [1022:1482] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 9: [1022:1484] 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 10: [1022:790b] 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61) [1022:790e] 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) IOMMU group 11: [1022:1490] 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 0 [1022:1491] 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 1 [1022:1492] 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 2 [1022:1493] 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 3 [1022:1494] 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 4 [1022:1495] 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 5 [1022:1496] 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 6 [1022:1497] 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 7 IOMMU group 12: [144d:a804] 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961 IOMMU group 13: [1022:148a] 02:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 14: [1022:1485] 03:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP IOMMU group 15: [1022:148c] 03:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller IOMMU group 16: [1022:1482] 20:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 17: [1022:1482] 20:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 18: [1022:1482] 20:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 19: [1022:1483] 20:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 20: [1022:1482] 20:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 21: [1022:1482] 20:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 22: [1022:1482] 20:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 23: [1022:1484] 20:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 24: [1022:1482] 20:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 25: [1022:1484] 20:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 26: [10de:1380] 21:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2) [10de:0fbc] 21:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1) IOMMU group 27: [1022:148a] 22:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 28: [1022:1485] 23:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP IOMMU group 29: [1022:1486] 23:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP IOMMU group 30: [1022:148c] 23:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller IOMMU group 31: [1022:1487] 23:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller IOMMU group 32: [1022:1482] 40:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 33: [1022:1483] 40:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 34: [1022:1482] 40:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 35: [1022:1482] 40:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 36: [1022:1482] 40:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 37: [1022:1482] 40:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 38: [1022:1482] 40:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 39: [1022:1484] 40:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 40: [1022:1482] 40:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 41: [1022:1484] 40:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 42: [1022:57ad] 41:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57ad IOMMU group 43: [1022:57a3] 42:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 44: [1022:57a3] 42:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 45: [1022:57a3] 42:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 46: [1022:57a3] 42:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 IOMMU group 47: [1022:57a4] 42:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4 [1022:1485] 47:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:149c] 47:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] 47:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller IOMMU group 48: [1022:57a4] 42:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4 [1022:7901] 48:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) IOMMU group 49: [1022:57a4] 42:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4 [1022:7901] 49:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) IOMMU group 50: [144d:a808] 43:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 IOMMU group 51: [8086:1539] 44:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) IOMMU group 52: [1d6a:11b1] 45:00.0 Ethernet controller: Aquantia Corp. AQC111 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] (rev 02) IOMMU group 53: [8086:2723] 46:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) IOMMU group 54: [1022:148a] 4a:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 55: [1022:1485] 4b:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP IOMMU group 56: [1022:1482] 60:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 57: [1022:1482] 60:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 58: [1022:1482] 60:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 59: [1022:1482] 60:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 60: [1022:1482] 60:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 61: [1022:1482] 60:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 62: [1022:1484] 60:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 63: [1022:1482] 60:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 64: [1022:1484] 60:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 65: [1022:148a] 61:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 66: [1022:1485] 62:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP I hope this information is helpful to someone. I'll be trying more stuff like setting up VMs soon.

My first sever and first Docker so apologies if the question is not clear or the answer is obvious: Followed tutorial as per old Spaceinvader One video (on deprecated Docker). The custom action bars option is toolbars settings "text under the icons" is not persistent on re-boot. Is it intended ?

I'm very much interested in hearing how things go.

I'm also experiecing this same issue with piHole which is using Custom br0 with an IP address I defined. After every reboot, I need to disable docker and enable docker to get Custom br0 to show up again.

Just a quick thank you Djoss -- I'm loving the ease of setting up reverse proxies for all the ridiculous stuff I previously had port-forwarded through my router. Using a DDNS integration between my router directly (AsusWrt Merlin firmware) to Google Domains, once I had the awareness to generate CNAME entries for the services I wanted access to -- and pointing those CNAMEs back to the synthetic DNS address -- using this proxy manager worked flawlessly. Really impressed with the ease and simplicity of this setup - especially since it's allowed someone like myself with little to no understanding of the complexities involved in manually creating a reverse proxy into a simple 10 minute affair. Thank you very, very much!

Hi, I am interested in trying a 8 GPU VM setup with an i9-7980xe running 8 VMs with GPU passthrough. Unfortunately, none of the X299 boards have more than 4 PCIex16 slots, making this impossible without any external setup. I stumbled upon this PCIe Splitter/Riser by SuperMicro and thought it could work. My only question is, are the two GPUs attached to one PCIe x16 slot going to give issues in IOMMU splitting, using ACS Override? I'm not sure how the chipset/mobo is going to recognise this setup. I'm fine if the GPUs run at x8 capacity as I'm not looking at very high-end gaming. Just need a single board 8 VM solution. Edit: I did a little bit of research. Apparently I need to look out for PCIe Bifurcation support on motherboards in order for this to work. Assuming I can find one, will IOMMU grouping still be an issue? Thanks! Ravyu

I figured it out. I needed to specify the byte offset of where the partition begins. For anyone who might have the same question in the future, here is what I did. From the unRAID command console, display partition information of the vdisk: fdisk -l /mnt/disks/Windows/vdisk1.img I was after the values in red. The output will looks something like this: [pre]Disk vdisk1.img: 20 GiB, 21474836480 bytes, 41943040 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xda00352d Device Boot Start End Sectors Size Id Type vdisk1.img1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT vdisk1.img2 206848 41940991 41734144 19.9G 7 HPFS/NTFS/exFAT[/pre] To find the offset in bytes, multiply the sector start value by the sector size to get the offset in bytes. In this case, I wanted to mount vdisk1.img2. 206848 * 512 = 105906176 Final command to mount the vdisk NTFS partition as read-only: mount -r -t ntfs -o loop,offset=105906176 /mnt/disks/Windows/vdisk1.img /mnt/test

You can limit everything. Cores, memory, etc. To limit cores add to extra parameters: --cpuset-cpus=0 to limit memory --memory=4G Additionally you can prioritize one docker app's cpu resources over another. Google docker run for a complete breakdown of everything possible. Personally, I think its in everyone's best interests to limit the resources of every app with the exception of Plex