Leaderboard

They also said a GPU is required for the host and another for the guest. My take on it is that nothing changes except for less code 43 happening

Big News from NVIDIA Just a few hours ago, NVIDIA added an article to its support knowledge base regarding GPU passthrough support for Windows VMs. While we've supported this functionality for some time, it was done without official support from the vendor themselves. This move by NVIDIA to announce official support for this feature is a huge step in the right direction for all of our VM pass through users. This should also help instill confidence in users that wish to pass through these GPUs to virtual machines without the worry that a future driver update would break this functionality. Let us know what you think about this announcement here!

Ich lösche eine evtl vorhandene Partition und nehme dann HD Tune Pro und mache die folgenden Tests jeweils 3x im Wechsel: Das dauert vielleicht 20 Minuten und dürfte denke ich 1% der Sektoren auf allen Magnetscheiben und Spuren umfassen. Zum Schluss schaue ich in "Health" ob sich die SMART-Werte verändert haben. Wenn nein, dann verbaue ich sie. Wenn dann wirklich noch defekte Sektoren vorhanden sein sollten, würde sich das ja beim Sync der Daten bemerkbar machen, aber bisher hatte ich so einen Fall noch nie. Immer wenn eine Platte eine Macke hatte, war sie schon bei den Tests kaputt.

Je reprends le message d'avertissement de @jonp qui mérite d'être aussi diffusé en français. Vous trouverez le sujet d'origine ici : https://forums.unraid.net/topic/104669-warning-unraid-servers-exposed-to-the-internet-are-being-hacked/ Bonjour à la communauté Unraid ! Ces derniers jours, nous avons constaté une augmentation significative du nombre de serveurs Unraid compromis en raison de pratiques de sécurité insuffisantes. Le but de ce post est d'aider notre communauté à contrôler que leurs serveurs sont sécurisés et de fournir des recommandations utiles sur les bonnes pratiques pour s'assurer que votre système ne devienne pas une autre victime. Nous vous invitons à consulter les recommandations ci-dessous sur votre/vos serveur(s) afin de vous assurer qu'ils sont sécurisés. Choisissez un mot de passe root robuste Comme pour de nombreux routeurs, les systèmes Unraid n'ont pas de mot de passe par défaut. Cela permet de s'assurer que vous pouvez rapidement et facilement accéder à la console de gestion immédiatement après l'installation du système. Cependant, cela ne signifie pas que vous ne devez pas en définir un. C'est très simple. Il suffit de naviguer dans l'onglet Utilisateurs et de cliquer sur root. Définissez ensuite un mot de passe. À partir de là, vous devrez vous authentifier à chaque fois que vous voudrez vous connecter au webGUI. En complément, il existe un plugin disponible dans Community Applications appelé Dynamix Password Validator. Ce plugin fournit des indications sur la robustesse du mot de passe que vous créez en se basant sur des règles de complexité (le nombre de lettres majuscules et minuscules, de chiffres, de symboles et la longueur totale du mot de passe sont utilisés pour en juger). Pensez à l'installer pour obtenir des conseils supplémentaires sur la robustesse des mots de passe. Examinez les mappages de ports sur votre routeur La redirection de ports vers votre serveur est nécessaire pour certains services spécifiques que vous souhaitez rendre accessibles par Internet, tels que Plex, les serveurs FTP, les serveurs de jeux, les serveurs VoIP, etc. Mais la redirection vers de mauvais ports peut exposer votre serveur à un important risque de sécurité. Voici quelques ports auxquels vous devez faire très attention lors de la redirection : Port 80 : Utilisé pour accéder au webGUI sans SSL (sauf si vous avez défini l'accès à un autre port sur la page des paramètres d'accès de gestion). NE PAS rediriger le port 80. La redirection de ce port par défaut vous permettra d'accéder au webGUI à distance, mais sans SSL pour sécuriser la connexion, les équipements entre votre navigateur et le serveur pourraient " sniffer " les paquets pour voir ce que vous faites. Si vous voulez rendre le webGUI accessible à distance, installez le plugin Unraid.net pour activer Mes Serveurs sur votre système, ce qui peut fournir une solution d'accès à distance sécurisée qui utilise le SSL pour assurer que votre connexion est entièrement cryptée. Port 443 : Utilisé pour accéder au webGUI avec SSL. Ce port n'est préférable au port 80 que si vous avez défini un mot de passe root. Si aucun mot de passe root n'est défini et que vous redirigez ce port, des utilisateurs non autorisés peuvent se connecter à votre webGUI et avoir un accès complet à votre serveur. En outre, si vous transférez ce port sans utiliser le plugin Unraid.net et My Servers, les tentatives de connexion au webGUI via un navigateur présenteront un avertissement de sécurité en raison de l'absence d'un certificat SSL. Envisagez de vous faciliter la vie et d'utiliser Unraid.net avec My Servers pour permettre un accès à distance simple, sûr et sécurisé à vos systèmes Unraid. NOTA : Lorsque vous configurez l'accès à distance dans My Servers, nous vous recommandons fortement de choisir un port quelconque au-dessus de 1000 plutôt que d'utiliser le port 443 par défaut. Port 445 : Utilisé pour SMB (partages). Si vous redirigez ce port vers votre serveur, tout partage public peut être connecté à n'importe quel utilisateur sur Internet. D'une manière générale, il n'est jamais conseillé d'exposer les partages SMB directement sur Internet. Si vous avez besoin de pouvoir accéder à vos partages à distance, nous vous suggérons d'utiliser un VPN de type Wireguard pour créer un tunnel sécurisé entre votre appareil et le serveur. En outre, si le disque flash lui-même est exposé à l'aide de SMB et que ce port est redirigé, son contenu peut facilement être supprimé et la clé que vous avez payée peut facilement être dérobée. Évitez tout simplement de le faire. Port 111/2049 : Utilisé pour NFS (partages). Bien que NFS soit désactivé par défaut, si vous utilisez ce protocole, assurez-vous de ne pas rediriger ces ports par votre routeur. Comme pour SMB, il suffit d'utiliser Wireguard pour créer un tunnel sécurisé à partir de tout périphérique distant qui doit se connecter au serveur via NFS. Port 22/23 : Utilisé par Telnet et SSH pour l'accès à la console. C'est particulièrement dangereux pour les utilisateurs qui n'ont pas de mot de passe root. Comme pour SMB, nous ne recommandons pas de rediriger ces ports du tout, mais plutôt de suggérer aux utilisateurs d'utiliser une connexion VPN Wireguard pour se connecter à l'aide de l'un de ces protocoles. Ports de la plage 57xx : Ces ports sont généralement utilisés par les VM pour l'accès VNC. Bien que vous puissiez rediriger ces ports pour permettre l'accès VNC à distance pour vos VM, la meilleure et plus facile façon de le faire est d'installer le plugin Unraid.net et d'activer Mes Serveurs. Cela garantit que ces connexions sont sécurisées via SSL et ne nécessite pas le transfert de ports individuels pour chaque VM. En règle générale, vous ne devriez pas avoir besoin de rediriger beaucoup de ports vers votre serveur. Si vous voyez une règle de transfert que vous ne comprenez pas, essayez de la supprimer, voyez si les utilisateurs se plaignent, et si c'est le cas, vous pouvez toujours la remettre en place. Ne mettez jamais et au grand jamais votre serveur dans la DMZ Même si vous pensez avoir parfaitement sécurisé votre serveur, il n'est jamais recommandé de le placer dans la zone démilitarisée de votre réseau. En faisant cela, vous redirigez chaque port de votre adresse IP publique vers votre serveur et tous les services accessibles localement sont également accessibles à distance. Même si vous pensez avoir sécurisé votre serveur, le placer dans la zone démilitarisée l'expose à des risques inutiles. Ne faites jamais ça. Envisagez de régler vos partages en mode 'privé' avec des noms d'utilisateurs et des mots de passe. L'accès aux partages sans mot de passe est très pratique. Nous le savons et c'est pourquoi nous ne vous obligeons pas à définir des mots de passe pour vos partages. Cependant, il y a un risque de sécurité pour vos données lorsque vous faites ça, même si vous ne transférez pas de ports vers votre serveur et que vous avez un mot de passe root fort. Si la sécurité d'un autre appareil de votre réseau, tel qu'un PC, un Mac, un téléphone, une tablette, un appareil IoT, etc. était compromise, il pourrait être utilisé pour établir une connexion locale aux partages de votre serveur. Par défaut, les partages sont configurés pour être accessibles en lecture/écriture de façon publique, ce qui signifie que ces appareils malveillants peuvent être utilisés pour dérober, supprimer ou chiffrer les données qu'ils contiennent. En outre, des utilisateurs malveillants pourraient également utiliser cette méthode pour placer sur votre serveur des données que vous ne souhaitiez pas. Pour ces raisons, si vous devez créer des partages publics, nous vous recommandons fortement de définir l'accès en lecture seule. Seuls les utilisateurs autorisés disposant d'un mot de passe fort doivent être en mesure d'écrire des données sur vos partages. Ne partagez pas votre clé USB, et si vous le faites, faites en sorte qu'elle soit sécurisée. La clé USB elle-même peut être exposée via SMB. C'est pratique si vous devez effectuer des modifications complexes sur votre système, comme modifier le fichier go dans le répertoire de configuration. Cependant, le périphérique flash lui-même contient les fichiers nécessaires pour démarrer Unraid ainsi que vos données de configuration (affectations de disque, partages, etc). Exposer ce contenu publiquement peut être extrêmement dangereux, aussi nous vous déconseillons de le faire à moins que ce ne soit absolument indispensable, et lorsque vous le faites, il est conseillé de le faire de manière sécurisée, en demandant un nom d'utilisateur et un mot de passe pour voir et modifier le contenu. Tenez votre serveur à jour Indépendamment des autres mesures que vous prenez, il est essentiel de maintenir votre serveur à jour avec la ou les dernières versions pour garantir sa sécurité. Il y a constamment des notifications de sécurité (CVEs) publiées pour les différents composants utilisés dans Unraid OS. Chez Lime Technology, nous faisons de notre mieux pour nous assurer que toutes les vulnérabilités sont corrigées en temps voulu par des mises à jour logicielles. Toutefois, ces mises à jour ne vous seront d'aucune utilité si vous ne les appliquez pas également en temps voulu. Il est simple de maintenir votre système d'exploitation à jour. Il suffit de naviguer dans Outils > Mise à jour du système d'exploitation pour vérifier la présence de mises à jour et les appliquer. Vous pouvez configurer des notifications pour vous avertir lorsqu'une nouvelle mise à jour est disponible à partir de la page Paramètres > Notifications. Autres recommandations de bonnes pratiques Configurez et utilisez WireGuard, OpenVPN ou nginxProxyManager pour un accès distant sécurisé à vos partages. Pour la configuration de WireGuard, voir ce tutoriel très pratique. Configurez le 2FA sur votre compte Unraid Forum. Configurez un serveur Syslog à distance. Installez le plugin Fix Common Problems. L'installation de ce plugin vous alertera en cas de multiples tentatives de connexion échouées et bien plus encore. Changez le mot de passe de votre modem pour quelque chose d'autre que le mot de passe par défaut. Envisagez d'installer ClamAV. En plus de toutes les recommandations ci-dessus, nous avons demandé à SpaceInvaderOne de préparer une vidéo avec encore plus de détails sur les bonnes pratiques liées à la sécurité d'Unraid. Nous posterons un lien dès que la vidéo sera disponible pour vous permettre de voir ce qu'il y a de plus à faire pour améliorer la sécurité de votre système. Il est vital que tous les utilisateurs examinent ces recommandations concernant leurs systèmes dès que possible afin de s'assurer que vous fassiez tout ce qui est nécessaire pour protéger vos données. Chez Lime Technology, nous nous engageons à faire d'Unraid une plateforme sûre et sécurisée pour tous vos contenus numériques personnels, mais notre capacité d'action dans ce domaine est très limité. Au final, c'est vous, en tant qu'utilisateur, qui êtes responsable de vous assurer que votre réseau et les appareils qui s'y trouvent sont conformes aux bonnes pratiques en matière de sécurité.

Hello Unraid Community! It has come to our attention that in recent days, we've seen a significant uptick in the amount of Unraid server's being compromised due to poor security practices. The purpose of this post is to help our community verify their server's are secure and provide helpful best-practices recommendations to ensuring your system doesn't become another statistic. Please review the below recommendations on your server(s) to ensure they are safe. Set a strong root password Similar to many routers, Unraid systems do not have a password set by default. This is to ensure you can quickly and easily access the management console immediately after initial installation. However, this doesn't mean you shouldn't set one. Doing this is simple. Just navigate to the Users tab and click on root. Now set a password. From then on, you will be required to authenticate anytime you attempt to login to the webGui. In addition, there is a plugin available in Community Apps called Dynamix Password Validator. This plugin will provide guidance on how strong of a password you're creating based on complexity rules (how many capital vs. lowercase letters, numbers, symbols, and overall password length are used to judge this). Consider installing this for extra guidance on password strength. Review port mappings on your router Forwarding ports to your server is required for specific services that you want to be Internet-accessible such as Plex, FTP servers, game servers, VoIP servers, etc. But forwarding the wrong ports can expose your server to significant security risk. Here are just a few ports you should be extra careful with when forwarding: Port 80: Used to access the webGui without SSL (unless you've rebound access to another port on the Management Access settings page). DO NOT forward port 80. Forwarding this port by default will allow you to access the webGui remotely, but without SSL securing the connection, devices in between your browser and the server could "sniff" the packets to see what you're doing. If you want to make the webGui remotely accessible, install the Unraid.net plugin to enable My Servers on your system, which can provide a secure remote access solution that utilizes SSL to ensure your connection is fully encrypted. Port 443: Used to access the webGui with SSL. This is only better than port 80 if you have a root password set. If no root password is set and you forward this port, unauthorized users can connect to your webGui and have full access to your server. In addition, if you forward this port without using the Unraid.net plugin and My Servers, attempts to connect to the webGui through a browser will present a security warning due to the lack of an SSL certificate. Consider making life easier for yourself and utilize Unraid.net with My Servers to enable simple, safe, and secure remote access to your Unraid systems. NOTE: When setting up Remote Access in My Servers, we highly recommend you choose a random port over 1000 rather than using the default of 443. Port 445: Used for SMB (shares). If you forward this port to your server, any public shares can be connected to by any user over the internet. Generally speaking, it is never advisable to expose SMB shares directly over the internet. If you need the ability to access your shares remotely, we suggest utilizing a Wireguard VPN to create a secure tunnel between your device and the server. In addition, if the flash device itself is exported using SMB and this port is forwarded, its contents can easily be deleted and your paid key could easily be stolen. Just don't do this. Port 111/2049: Used for NFS (shares). While NFS is disabled by default, if you are making use of this protocol, just make sure you aren't forwarding these ports through your router. Similar to SMB, just utilize Wireguard to create a secure tunnel from any remote devices that need to connect to the server over NFS. Port 22/23: Used by Telnet and SSH for console access. Especially dangerous for users that don't have a root password set. Similar to SMB, we don't recommend forwarding these ports at all, but rather, suggest users leverage a Wireguard VPN connection for the purposes of connecting using either of these protocols. Ports in the 57xx range: These ports are generally used by VMs for VNC access. While you can forward these ports to enable VNC access remotely for your VMs, the better and easier way to do this is through installing the Unraid.net plugin and enabling My Servers. This ensures that those connections are secure via SSL and does not require individual ports to be forwarded for each VM. Generally speaking, you really shouldn't need to forward many ports to your server. If you see a forwarding rule you don't understand, consider removing it, see if anyone complains, and if so, you can always put it back. Never ever ever put your server in the DMZ No matter how locked down you think you have your server, it is never advisable to place it in the DMZ on your network. By doing so, you are essentially forwarding every port on your public IP address to your server directly, allowing all locally accessible services to be remotely accessible as well. Regardless of how "locked down" you think you actually have the server, placing it in the DMZ exposes it to unnecessary risks. Never ever do this. Consider setting shares to private with users and passwords The convenience of password-less share access is pretty great. We know that and its why we don't require you to set passwords for your shares. However, there is a security risk posed to your data when you do this, even if you don't forward any ports to your server and have a strong root password. If another device on your network such as a PC, Mac, phone, tablet, IoT device, etc. were to have its security breached, it could be used to make a local connection to your server's shares. By default, shares are set to be publicly readable/writeable, which means those rogue devices can be used to steal, delete, or encrypt the data within them. In addition, malicious users could also use this method to put data on your server that you don't want. It is for these reasons that if you are going to create public shares, we highly recommend setting access to read-only. Only authorized users with a strong password should be able to write data to your shares. Don't expose the Flash share, and if you do, make it private The flash device itself can be exposed over SMB. This is convenient if you need to make advanced changes to your system such as modifying the go file in the config directory. However, the flash device itself contains the files needed to boot Unraid as well as your configuration data (disk assignments, shares, etc). Exposing this share publicly can be extremely dangerous, so we advise against doing so unless you absolutely have to, and when you do, it is advised to do so privately, requiring a username and password to see and modify the contents. Keep your server up-to-date Regardless of what other measures you take, keeping your server current with the latest release(s) is vital to ensuring security. There are constant security notices (CVEs) published for the various components used in Unraid OS. We here at Lime Technology do our best to ensure all vulnerabilities are addressed in a timely manner with software updates. However, these updates are useless to you if you don't apply them in a timely manner as well. Keeping your OS up-to-date is easy. Just navigate to Tools > Update OS to check for and apply any updates. You can configure notifications to prompt you when a new update is available from the Settings > Notifications page. More Best Practices Recommendations Set up and use WireGuard, OpenVPN or nginxProxyManager for secure remote access to your Shares. For WireGuard set up, see this handy getting started guide. Set up 2FA on your Unraid Forum Account. Set up a Remote Syslog Server. Install the Fix Common Problems plugin. Installing this plugin will alert you to multiple failed login attempts and much, much more. Change your modem password to something other than the default. Consider installing ClamAV. In addition to all of the above recommendations, we've asked SpaceInvaderOne to work up a video with even more detailed best-practices related to Unraid security. We'll post a link as soon as the video is up to check out what other things you can do to improve your system security. It is of vital importance that all users review these recommendations on their systems as soon as possible to ensure that you are doing all that is necessary to protect your data. We at Lime Technology are committed to keeping Unraid a safe and secure platform for all of your personal digital content, but we can only go so far in this effort. It is ultimately up to you the user to ensure your network and the devices on it are adhering to security best-practices.

We like the announcement. 🚀🚀

No. The age just set's an "mtime" value for the find command. So it will look for everything greater than 0 days old.

Best news of 2021 so far IMO

It should stay like that now that you've manually activated, you should be able to stop/restart the docker, and do "force update" and verify that it still works after that.

You can try the options in the link above, there's nothing to lose.

Doh! Sorry for not reading first. Confirmed resolved by the updated runc version.

see recommended post at top of the screen 'glibc causing random errors'

They need to be installed on the client as well. When connecting to a moded server the client ether a: downloads them from the server or b: marks them as subscribed and lets steam down load them, I'm not sure which... as far as I know the --crossplay flag only allows Epic clients to connect to un-moded servers...

Great! This solved my problem. Download unraid ZIP file, find the "go" file (doesn't have a extension), copy it to your server into /boot/config/ and reboot your machine. Thank you very much!

New nvidia driver out: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-465-Linux-Beta

Hi Dan, Following this topic. Been having stability issues myself since upgrading to 6.9.1. Random kernal crashes, where i can only do a hard reset, and since 2 - 3 days unresponsive webgui, as in, i can log in, but after that nothing. On next hard reset i will enable sys log to flash too ;).

I realized that after posting the comment, but since the comment was still valid I decided to leave it One good side-effect of this last release issue is that it has prompted me to add syntax checking of the plugin's files to the scripts I use for automating deploying files and building the package so hopefully any such issue is less likely to make it into a release in the future.

Found the issue! i didnt had device_tags = ["ID_SERIAL"] set in [[inputs.diskio]] All working now!

As @limetech stated, I did open up a issue a couple of days ago on an internal bug tracker

Click on the disk, in the case above md4=disk4, then click the scrub button, after it's done look at the syslog for the list of corrupt files, then just delete them or restore from backups.

Yep right after I switched over to a VM they came out with native support for an SSD on the pi go figure but no regrets its been rock solid since starting it

@lnxd Maybe worth mentioning it's an 8 GB model of the RX 570 in here

SOLVED Well well, @JorgeB It seems you are my hero of the day! You got anything where i can tip you a drink? Thank you very much. It worked exactly as you said.

If Docker/VM services are using the cache pool disable them, unassign all cache devices, start array to make Unraid "forget" current cache config, stop array, reassign all cache devices (there can't be an "All existing data on this device will be OVERWRITTEN when array is Started" warning for any cache device), re-enable Docker/VMs if needed, start array.

A difference is that people here will not complain if you do not use ECC.

Try using mlxconfig to confirm SR-IOV is properly enabled on the card - step 3 here: https://mymellanox.force.com/mellanoxcommunity/s/article/howto-configure-sr-iov-for-connectx-3-with-kvm--infiniband-x Edit: You could probably follow the firmware update instructions in my post, but replace fw-ConnectX2-rel.mlx with fw-ConnectX3-rel.mlx I'm not sure if the format of the ini file is the same for ConnectX-3 though, ie this part: num_pfs = 1 total_vfs = 64 sriov_en = true Maybe export what's in the current config mstflint -d mtxxxxx_pci_cr0 dc > backup.ini What's in the [HCA] section? I did all this on a Windows machine, but there are Mellanox tools in unRAID Apps: Mellanox-Firmware-Tools Edit2: Some more bed-time reading for you! https://forums.servethehome.com/index.php?threads/how-to-enable-sr-iov-on-connectx-3.24321/

SOLVED I have no idea how I solved it but here is what happened: I created a new usb stick with 6.9.1 on it. Copied all the config files from a backup of 6.8 on it. Restarted my server, selected the new boot drive and restarted. Then the server booted from the old (non functioning one) and... wel it suddely worked. Then proceded to upgrade it to 6.9.1 and everything is fine since. Thanks for your help!

At boot time only one of the cache devices (sdd) had a valid btrfs filesystem and it didn't mount with this error: Mar 27 20:11:45 Tower emhttpd: /mnt/cache mount error: Too many missing/misplaced devices This suggests the pool wasn't redundant, you can see here for some recovery options, from sdd only, but even if it works and the pool wasn't redundant it won't be complete.

The simplest option would be to mirror the syslog to flash:

Yeah I think it was the controller causing it to fail out. Been running for 4 hours in an external enclosure without an error.

Danke fürs Feedback. Leider doch nicht die 100 MB/s geknackt. Aber jetzt weißt du zumindest wie du es in Zukunft schneller bekommst

I wasn't aware the epic client supported mods. If you do not wish to use the steamCMD tools, then you will want to copy the mods from your PC (<pathtoARK>\ShooterGame\Content\Mods\) muber of the folder that contains the mod and the number.mod file, over to your unraid machine in <pathtoARK>/ShooterGame/Content/Mods/ then ether the modID in ether the Config/LinuxServer/GameUserSettings.ini as ActiveMods=2229978458,1083349027,1211297684 or add them to the docker "Game Parameters:" variable as ?GameModIds=ModID1,ModID2

Thank you for the ARK docker @ich777 ! I managed to get it to work even though it was a bit more complicated as I use the Epic Client and wanted to keep a password my server. What is the recommended way if I want to to install Mods on the ARK server?

Done.

What version of windows 10? It's like I said with mellanox drivers, they're all kinda tied up in licensing crap... My suggestion would be to use something like 7zip to manually extract an older version of the drivers from the executable and then attempt manual installation. For windows and virtual functions, intel (and some chelsio) are really the only sure fire way to ensure compatibility thanks to the crap nvidia and mellanox have pulled with their drivers.

I'm sure someone will post it.

Do not run it as privileged. It's a big security risk. Binhex posted in the MinecraftServer (not MineOS) support thread that it can be temporarily fixed with a simple command (after every reboot), until it's permanently fixed in a future Unraid update:

Depending on how long your router allows DHCP addresses to be reserved and how often your server is offline will have a lot to do with determining if the server IP address can be assigned to another device. Some routers basically let DHCP assigned addresses persist permanently while others have a limit of 7 days or less. Once your server grabs the preferred address, nothing else should get that same address assigned unless the server is forced to give it up or is offline. I once had a router that did not make it easy to assign static IP addresses but allowed fairly long lease time. To make sure that address would never be assigned elsewhere I did as John M said and set my DHCP pool to begin at 192.168.1.21 and left anything below .21 to be assigned as static addresses. Worked great. My current router allows static IPs to be assigned, but, I still keep DHCP to a range outside of the static addresses. Just disconnecting the phone would not necessarily let the router reassign that address immediately unless you rebooted the server and it saw that address was available.

I think parity2 should be OK but after rebuilding disk3 you might run a parity check. In any case you will still have the original disk3 and should wait until you are confident in everything to do anything with it.

Regarding the icons and authentication, it seems the images are available at the same path in the unraid API docker. I pointed the base url at that port and now it works without authentication

Dann verwende doch einfach das existierende Beispiel von swag unter "/swag/nginx/proxy-confs/homeassistant.subdomain.conf". Setze deine Dyndns subdomain bei "server_name deinesubdomain.*;" ein. Dann ersetze "set $upstream_app containername" durch "set $upstream_app deine.ip.adr.esse"

How can I get mc to work with a mouse from the built in unRAID terminal accessible from the WEBUI?

Ich nutze den Original Plex Container und habe das und noch viel mehr manuell eingestellt: --no-healthcheck = kein ständiges Schreiben auf die SSD (siehe Bug Report) --mount = RAM-Transcoding + Netzwerk-Typ: Plex ID und Nutzerrechte: Lokale IP festlegen damit lokale Zugriffe nicht wie externe behandelt werden (um generelles Transcoding zu verhindern): + Pfade zu den Mediendateien (meine Musik liegt auf der SSD, daher /mnt/cache): Hardware-Transcoding aktivieren: Alle notwendigen Ports freigeben: Reine Lese-Rechte legt man beim Anlegen des Pfades fest bzw wenn man ihn bearbeitet:

maybe add a feature => buton to mark the topic as solved automaticaly, would be nice

I would recommend to switch to postgres11 instead of MongoDB. For me this caused a big improvement in upload speeds and also CPU utilisation. I posted how to set it up on the Nextcloud thread.

I don't think the OP posts in anyway "reassure" that it can be done. Code 43 is Nvidia anti-consumer way (which is their MO) to force people into buying expensive Quadro cards to use in VMs. Once you understand that, (most of the) potential fixes will become rather obvious i.e. just hide any potential clues to the Nvidia driver that it is running in a VM. If Hyper-V is on, it probably is in a VM ==> disable Hyper-V. Note: if you are going to disable / enable Hyper V, start a new template! Editing an existing template sometimes doesn't disable Hyper-V correctly - been there, done that. If a card is loaded on a machine and then switched to a different machine without a proper reset then it's probably in a VM ==> boot host in legacy mode (so no option rom is loaded), vfio-pci stubbing / use a dedicated primary GPU for the host (so the passed-through GPU isn't loaded on the host), dumping vbios (so the card is reset properly) Nvidia will update their drivers to wise up to workarounds ==> use older driver Some cards just don't like some inexplicable things about the VM ==> boot VM in OVMF, use Q35 machine type (which has better PCIe support - note will need some additional manual xml lines to run in full PCIe x16 until the new qemu version in included in Unraid) Those are the "TL;DR". For the longer read:

newperms /mnt/user/NameOfShare