Everything posted by psychofaktory
-
[Support] knex666 - Nextcloud
As far as I can see requirements are Redis and a reverse proxy. In the docker-compose.yml you linked, instead of nginx reverse proxy, traefik proxy is used. It seems that the official nextcloud docker is also used. So could it be possible?
-
[Support] knex666 - Nextcloud
Hi, I use this great Docker-Container behind Nginx Proxy Manager. Database is MariaDB. Also I've a Redis-Container running as cache for Nextcloud. What do I have to do to make the "High Performance Backend for Files" working?
-
Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array
Why does it scan public IPs here?
-
Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array
Hello, Via the view of the active processes I noticed that Unraid constantly tries to scan any external IP addresses for port 445 (SMB): Further investigation has revealed that the Unassigned.Devices plugin seems to be the culprit. root@ADL15-SRV01:~# grep -rnw '/boot/' -e '/dev/tcp' root@ADL15-SRV01:~# grep -rnw '/usr/' -e '/dev/tcp' /usr/local/emhttp/plugins/unassigned.devices/scripts/port_ping.sh:21: timeout -s 5 $timeout bash -c "(echo >/dev/tcp/${ip}/${port}) &>/dev/null && echo $ip" 2>/dev/null & /usr/local/emhttp/plugins/ca.backup2/scripts/backup.php:300: Why is the plugin doing this and how can I prevent it?
-
Unraid führt unerwünschte Portscans durch
Hier das Ergebnis der Suche: root@ADL15-SRV01:~# grep -rnw '/boot/' -e '/dev/tcp' root@ADL15-SRV01:~# grep -rnw '/usr/' -e '/dev/tcp' /usr/local/emhttp/plugins/unassigned.devices/scripts/port_ping.sh:21: timeout -s 5 $timeout bash -c "(echo >/dev/tcp/${ip}/${port}) &>/dev/null && echo $ip" 2>/dev/null & /usr/local/emhttp/plugins/ca.backup2/scripts/backup.php:300: exec("echo test 2>/dev/null > /dev/tcp/$containerIP/$containerPort",$output,$error); Scheint tatsächlich von dem unassigned.devices-Plugin zu kommen. Aber warum macht es das?
-
Unraid führt unerwünschte Portscans durch
Unraid ist Version 6.9.2 2021-04-07. Alle Komponenten sind auf dem aktuellen Stand. Die Diagnostics habe ich mit angehängt. Habe Unraid inzwischen neu gestartet (lief zuvor seit 52 Tagen an Stück). Seitdem sind keine Anfragen mehr aufgetreten. Wäre es möglich dass ein Plugin eine Fehlfunktion hatte und die Portscans nur ein unerwünschter Nebeneffekt waren? Vor einiger Zeit hatte ich eine SMB-Freigabe mit dem Unassigned Devices Plugin eingebunden und später wieder getrennt. Ich habe so einen Verdacht dass es hier einen Zusammenhang geben könnte. adl15-srv01-diagnostics-20211006-0818.zip
-
Unraid führt unerwünschte Portscans durch
Über die Ansicht der aktiven Prozesse ist mir aufgefallen, dass Unraid permanent versucht irgendwelche externen IP-Adressen nach Port 445 (SMB) abzuscannen: Wie kann ich den Verursacher für dieses unerwünschte Verhalten ausfindig machen?
-
[Support] ich777 - Jellyfin AMD/Intel/Nvidia [DEPRECATED]
Thanks for your reply! Port 8096 was accessible. I tried https://10.20.20.14:8920 today again and this time it worked. No clue what happened since yesterday... But then I recognized DLNA-server isn't working anymore when https is turned on. So now I use the variant with the reverse proxy as you mentioned. Thanks for that information. Didn't know that before 🙂
-
[Support] ich777 - Jellyfin AMD/Intel/Nvidia [DEPRECATED]
Hi, I'd like to access the webgui via https. WebGUI-Port in the container-config for https is the default Port 8920. In the Jellyfin settings I activated https and provided a valid public certificate. But I'm not able to access the webgui. It's said connection refused; page not reachable. Although I set port 8920 in the container settings, the port is not shown at the port assignment. What is wrong here?
-
Hardware-Transcoding nicht möglich
Danke für den Hinweis. Mit der Info bin ich an den Maintainer des Containers herangetreten und hab dort mein Problem geschildert. Tatsächlich war der Mesa-Treiber veraltet und hatte die Ryzen 4000 Prozessoren noch nicht unterstützt. Zudem hatte die FFMPEG-Version wohl nicht gepasst. Nach den entsprechenden Anpassungen durch den Maintainer funktioniert jetzt alles wie gewünscht 🙂
-
Hardware-Transcoding nicht möglich
Ja, die Dateien scheinen enthalten zu sein: # cd /usr/lib/x86_64-linux-gnu/dri/ # ls i915_dri.so iHD_drv_video.so nouveau_drv_video.so r300_dri.so radeon_dri.so swrast_dri.so i965_dri.so kms_swrast_dri.so nouveau_vieux_dri.so r600_dri.so radeonsi_dri.so virtio_gpu_dri.so i965_drv_video.so nouveau_dri.so r200_dri.so r600_drv_video.so radeonsi_drv_video.so vmwgfx_dri.so # Der Versuch ist noch ausstehend.
-
Hardware-Transcoding nicht möglich
Anhand der beiden Treads habe ich einige Ansatzpunkte gefunden die potentielle Fehlerquellen sein könnten. Ich habe die BIOS-Einstellungen überprüft und festgestellt, dass tatsächlich PCIe als primäres Anzeigegerät voreingestellt war, obwohl hier garkeine dedizierte Grafikkarte verbaut ist. Das habe ich auf interal graphics umgestellt. Dann hab ich überprüft ob die VM die ich zusätzlich noch unter Unraid laufen lasse die iGPU vielleicht für sich beansprucht. Das war aber nicht der Fall. Einen HDMI-Dummy habe ich am internen Grafikadapter angeschlossen, da der Server ansonsten headless läuft. Den habe ich testweise abgehängt. Bisher leider alles ohne Erfolg. ich habe zum Monitoring und für Eingriffe über die Konsole (wie BIOS-Updates) noch einen Monitor via Displayport angeschlossen. Ist in dieser Konstellation ein gleichzeitiger Betrieb von Transcoding und Bildausgabe möglich?
-
Hardware-Transcoding nicht möglich
Hallo, ich habe mir hier einen kleinen Server aus folgenden Komponenten zusammengestellt: AMD Ryzen 3 PRO 4350G mit 32 GB DDR4 ECC RAM auf einem ASUS B550M-C Pro. Diese Konstellation sollte unter Unraid 6.9.2 nach meinem Kenntnisstand grundsätzlich in der Lage sein Transcodierungen in Hardware auch innerhalb von Docker-Containern durchführen zu können. Mein Ziel wäre es im offiziellen Docker-Container von BubbleUPnP GPU transcoding nutzen zu können. Laut der zugehörigen Dokumentation wird Va-API unterstützt. In der Webkonsole des BubbleUPnP-Servers gibt es das zu eine Schaltfläche "Perform GPU Transcoding test". Hier erhalte ich aber nur die folgende Fehlermeldung: Die zugehörige Log-Datei aus dem Container habe ich mit angehängt. Zur Aktivierung der Hardwaretranscodierung hatte ich gemäß dieser Vorlage unter Unraid die Datei amdgpu.conf angelegt. chmod -R 777 /dev/dri wie in einer anderen Anleitung hatte ich unter Unraid bereits ebenfalls durchgeführt. ls -la /dev/dri gibt bei mir unter Unraid folgendes aus: drwxrwxrwx 3 root root 100 Jul 20 16:22 ./ drwxr-xr-x 16 root root 3460 Jul 20 16:22 ../ drwxrwxrwx 2 root root 80 Jul 20 16:22 by-path/ crwxrwxrwx 1 root video 226, 0 Jul 20 16:22 card0 crwxrwxrwx 1 root video 226, 128 Jul 20 16:22 renderD128 /dev/dri habe ich im Docker entsprechend durchgereicht: Zwischenzeitlich habe ich die amdgpu.conf wieder entfernt und stattdessen das Plugin Radeon-TOP, das Hardware-Transcoding ebenfalls aktivieren soll, zusammen mit GPU Statistics im Einsatz. Getestet hatte ich außerdem einen alternativen Container für den BubbleUPnP-Server. vainfo gibt hier folgendes aus: error: XDG_RUNTIME_DIR not set in the environment. error: can't connect to X server! libva info: VA-API version 1.4.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_4 pci id for fd 4: 1002:1636, driver (null) libva error: /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so init failed libva info: va_openDriver() returns 2 vaInitialize failed with error code 2 (resource allocation failed),exit Wo liegt hier der Fehler? BubbleUPnPServer.log