wambo

First off: yes I am guilty, the post I read even had a warning in it But I still tried `powertop --autotune` to see the results, and at first I didn't notice anything not working. But then I saw that my 3rd array disk (smallest current one and also oldest, makes sense that it maybe can't handle some options) was marked as disabled (disabled, contents emulated). I didn't find any way to activate it, and reading about powertops said that it's changes shouldn't be persistent, I did reboot my system. and... it completely didn't find the disk anymore. I did not find anything about disabling the med_power_with_dipm option again... So I tried a shutdown, waited a few min and started again. I'm back to "device disabled content emulated". I have 2 cache SSDs and my array is 2x 8TB, 1x 6TB + 8TB Parity. Since my current MB only has 4 SATA Ports 2 HDDs are connected via an PCIe (x4) to SATA Card. I am not 100% sure that the 6TB (problematic) one is connected via this, but at least one other drive connected there is working, so I am not sure this is the issue... lsscsi still shows the disk. I'm not sure about the SMART readings that Unraid shows - are they also "emulated" or current? This thread suggests that the disk needs to be rebuild - but I cannot find an option for it, with the array running or not... So I'm at a loss on how to proceed...

No idea about the necessity, but you can copy the file into the appdata/clouflared foldder on your unraid system which is available as /appdata/ inside the container. So you'd write /appdata/cert.pem - worked for me I have a question on my own: does this support multiple tunnels? How would I add another tunnel token?

I'm trying to find out why my (single only) compose stack is not starting after a reboot. I have the autostart toggled on, and in syslog I can see Apr 19 03:25:49 <host> root: Starting compose stack: proxmox But I always have to start it by hand. I also noticed that the plugin reinstalled on the last reboot (possibly on every?) even though there was not update in months... but since it still tried to start the stack I suspect the issue somewhere else...

I meant the difference between "plugin" and "test mode" I have to admit, this might be an isolated me-issue. I do have a share named SHARE (free access). Oh noooo. OK I see. I picked a horrible spot, SHARE and data. Sorry. Another point, the mover finished yesterday and at the end it didn't move enough to bring the usage down to 65% (move above) or even the 40% *Free down to* thresholds even though I found plenty of shares with enough data to be moved on them... I have no settings about spareseness or age activated...

I just went to analyse why most of my services stopped - turns out cache was at 100% usage (ahhhhhhh) 2 days ago the mover was sheduled, so I went to find out, why it didn't run --> Forgot to switch off test-mode - First point: This is a bit of a trap, I read 3 times the line from 1 above: "No - setting effectively disabled this plugin". I'd suggest rewording this a little bit, so nobody else falls prey Or at least make the key word bold. - I went to check the output of the dry run, only to find an empty /tmp/ca.mover.tuning ?? Something broke there... /tmp is set as parent log folder path and the help text for the test mode definitely states it should write something there... - I swapped off test mode, started mover manually, checked in syslog and found a lot of those: Apr 17 17:39:18 <hostname> move: /usr/local/emhttp/plugins/ca.mover.tuning/age_mover: eval: line 1023: syntax error near unexpected token `newline' Apr 17 17:39:18 <hostname> move: /usr/local/emhttp/plugins/ca.mover.tuning/age_mover: eval: line 1023: `find "/mnt/cache_ssd_big/SHARE" -type f -depth -not -name '.placeholder' -printf '%T@|%s|%S|%n|%i|%p|\0' | awk -v RS='\0' -v FS='|' -v SPARSENESS='0' -v PRIMARYSTORAGENAME='cache_ssd_big' -v SECONDARYSTORAGENAME='user0' -v SHARENAME='SHARE' -v SHAREUSECACHE='yes' -v PRIMARYSIZETHRESH='650132494336' ' { printf "%s|%s|%s|%s|%d|%d|%d|%d|%d|%d|%s\n", PRIMARYSTORAGENAME, SECONDARYSTORAGENAME, SHARENAME, SHAREUSECACHE, $1, PRIMARYSIZETHRESH, $2, $3, $4, $5, $6}'>>' I couldn't find anything wrong in that line, but I have no clue how to show linebreaks in bash/nano/... Also now with test mode off, the log and list files in /tmp/ca.mover.tuning are being created... - I think the logs should mention which share was just processed: Apr 17 19:22:30 <hostname> move: Mover action: cache_ssd_big->user0 (cache:yes). Pool is above moving threshold percentage: 87% >= 65%. Apr 17 19:22:30 <hostname> move: Updated Filtered filelist: /tmp/ca.mover.tuning/Filtered_files_2025-04-17T192228.list for SHARE Apr 17 19:22:31 <hostname> move: Mover action: no action, only cache_ssd_big used (cache:only). Apr 17 19:23:05 <hostname> move: Mover action: cache_ssd_big->user0 (cache:yes). Pool is above moving threshold percentage: 87% >= 65%. Apr 17 19:23:05 <hostname> move: Updated Filtered filelist: /tmp/ca.mover.tuning/Filtered_files_2025-04-17T192228.list for data

Fix Commons Problems made me aware that I'm stuck on an outdated version (2023.12.19) and recommends going with the version by masterwishx. I can find it in Apps but sadly updating does not work (it starts but skips after noticing that 2023.12.19 is installed - see log below) I guess the next option is uninstall and reinstall, can I just save the 'ca.mover.tuning.cfg' and overwrite it afterwards? plugin: updating: ca.mover.tuning.plg Executing hook script: pre_plugin_checks 7.0.1 +============================================================================== | Skipping package ca.mover.tuning-2023.12.19-x86_64-1 (already installed) +============================================================================== Backup current mover binary, command may fail depending on version of unRAID Creating Soft link for 6.12 RC8 or newer since /usr/local/sbin/move is now lcoated in /usr/local/bin/move ---------------------------------------------------- ca.mover.tuning has been installed. Copyright 2018, Andrew Zawadzki Version: 2023.12.19 ---------------------------------------------------- plugin: ca.mover.tuning.plg updated Executing hook script: post_plugin_checks Updating support link

So, basically my setup has been working for months now. But every now and then (can't figure out what causes it/ if it is periodically) the containers routed through delugevpn loose connection (I can neither access their WEBUI nor can they communicate with other containers). I then need to restart those vpn "client" containers and usually it works again. Sometimes I need to restart all ( a few times - and pray). Today I checked, and Radarr logs are stating that they couldn't grab history at 2024-09-23 06:16:02 In the delugevpn supervisord.log I find this: 2024-09-23 07:49:34,996 INFO reaped unknown pid 56 (terminated by SIGTERM) 2024-09-23 07:49:35,001 WARN received SIGTERM indicating exit request 2024-09-23 07:49:35,001 DEBG killing watchdog-script (pid 277) with signal SIGTERM 2024-09-23 07:49:35,002 INFO waiting for start-script, watchdog-script to die 2024-09-23 07:49:35,005 DEBG 'watchdog-script' stdout output: [info] Waiting for child processes to exit... 2024-09-23 07:49:35,005 DEBG 'watchdog-script' stderr output: Terminated 2024-09-23 07:49:35,005 DEBG received SIGCHLD indicating a child quit 2024-09-23 07:49:35,516 DEBG 'watchdog-script' stdout output: [info] Child process with pid id '553 644' still running, waiting... 2024-09-23 07:49:36,043 DEBG 'watchdog-script' stdout output: [info] Child process with pid id '553 644' still running, waiting... 2024-09-23 07:49:36,047 DEBG 'watchdog-script' stdout output: [info] All child processes exited, exiting while loop... 2024-09-23 07:49:36,047 DEBG 'watchdog-script' stdout output: [info] All child processes exited, exiting 'watchdog.sh' script... 2024-09-23 07:49:36,049 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22393654157312 for <Subprocess at 22393654162832 with name watchdog-script in state STOPPING> (stdout)> 2024-09-23 07:49:36,049 DEBG fd 15 closed, stopped monitoring <POutputDispatcher at 22393654161632 for <Subprocess at 22393654162832 with name watchdog-script in state STOPPING> (stderr)> 2024-09-23 07:49:36,049 INFO stopped: watchdog-script (exit status 0) 2024-09-23 07:49:36,049 DEBG received SIGCHLD indicating a child quit 2024-09-23 07:49:36,050 DEBG killing start-script (pid 276) with signal SIGTERM 2024-09-23 07:49:37,052 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22393656097248 for <Subprocess at 22393670069632 with name start-script in state STOPPING> (stdout)> 2024-09-23 07:49:37,052 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22393655384480 for <Subprocess at 22393670069632 with name start-script in state STOPPING> (stderr)> 2024-09-23 07:49:37,052 WARN stopped: start-script (terminated by SIGTERM) 2024-09-23 07:49:37,053 DEBG received SIGCHLD indicating a child quit What could have caused this restart? I can't tell from those logs tbh. If I can't find out / solve those restarts, can I make the other (routed) containers reboot along? I'd even be up to setting those containers back up as compose stack, since I want to move a bunch of services away from my unraid server anyway.

I'm trying to think of a way to make this run in addition with my existing setup: Obsidian Installations on my windows machines with obsidian-git for syncing But I'd also like to be able to access this from remote, when I'm not on my own computer, issues I'm seeing: - how to access the docker securely? (doesn't seem to run on https?) What are ppl using to "secure" the access to the ksmvnc? As a LIO image there is support for swag as reverse proxy, but I really want a proper layer of protection there...

Hardware Raids sind deshalb mWn halbwegs überflüssig, weil es die externen Chips kaum noch braucht um die Paritätsberechnungen / Raid-Aufteilung vorzunehmen. Ich bin mir nicht sicher, ob das Gerät wirklich ein NAS ablöst oder eher "entlastet". Es kann nun mal keine HDDs selbst aufnehmen. Mein ähnliches Gerät bringt auch nur einen Adapter mit (mSata oder evtl. proprietär auf SATA, inkl. Strom, weiß nicht ob das für HDDs langt), ich weiß gar nicht ob es 2 SATA-Anschlüsse gibt? Aufgelistet ist auf Amazon für das RJ42 auch nur einer + das Punch-Through-Hole. NAS behalten wäre natürlich mehr Stromverbrauch (und evtl. kein Verkaufswert des NAS). Falls nur ein SATA-Anschluss würde sich die Lösung 1 erübrigen (SATA kann erstmal nur 1 device pro Port) - sonst musst du über Multiplier Chips gehen, die gibt es vermutlich auch in solchen externen Gehäusen, aber da würde die Geschwindigkeit leiden (evtl. bei HDDs auch wieder kein Problem). Deshalb würde ich darüber nachdenken, HDDs in der NAS zu belassen, und das neue Gerät nur mit SSDs --> 2x nVME zu betreiben. Das passt rein, dort können alle Dinge wie VMs, Docker, Services laufen und die großen Datenmengen werden per SMB vom NAS eingebunden. Damit wird zwar das Cache <-> Array System von Unraid etwas obsolet, aber evtl. kann man da auch irgendwie tricksen, z.B. die HDDs von der Synology irgendwie als devices einbinden (und damit das Array bauen) oder Unraid irgendwie vermitteln, dass es vom Cache auf eine Freigabe schiebt und zurück. Außerdem: Auch der Cache sollte mit Parität laufen, besonders da hier die Änderungen liegen, von denen es vermutlich noch kein Backup gibt! Lösung 2 finde ich nicht gut, das RAID auf ein externes Gehäuse umzulegen, wie läuft das ab, wenn eine Platte abraucht? Wie wird das Resilvering angestoßen? Du hast dann auch nicht den Vorteil von Unraid, dass du einfach die andere Platte einlesen könntest. Was noch ginge, wäre jede Platte per USB anzuschließen, dann könntest du trotzdem das Unraid Array nutzen, und USB Anschlüsse hat das Ding ja auch genug (ahhh nur 1x 3.0 also evtl. ein kleiner Hub dazwischen? Falls es USB-HDD-Gehäuse gibt, die beide Devices direkt übertragen, dann wäre das ebenfalls eine Möglichkeit. Ich würde sagen: Gehäuse 3D Drucker falls 2 Sata Ports > Externes HDD Bay mit SATA Multiplier = Externes Gehäuse mit USB (ohne RAID, sondern einzelne Devices) > NAS für HDDs >> alles andere

I got redirected here from the changelog and tried to follow the steps in the first post. This is not accurate enough (anymore?, maybe it changed). Under tools I have several items with "System" in the name, but none just "System". Under "System devices" I can see the ethernet controller, so it should maybe be adjusted to this? My entry says "RTL8111/8168/8211/8411" - from my mainboards datasheet I can tell it is a RTL8111f. I'd also suggest adding some clarification whether this plugin is recommended if one of the supported chipsets is listed, or whether it means the user still needs to clarify whether a supported chipset (so which out of that list from the entry) is being used.

I just checked my bookmarks what port I was using to access the VPN before and changed the port options to that, I believe the configs in the jdownloader should've kept the old values (which I probably adjusted months ago after initial setup) About the run command: it finishes successfully. The command finished successfully! I think I should've stated better in my edit that I managed to fix my problem - although I don't know why port allocations changed. That is what I wanted to leave here (along with how to fix my problem), because maybe there was some rare issue behind it 🤷‍♂️

I guess hardware issue is one of the downside of reusing outdated hardware 😕 I'm gonna try relocating some important services, then run the memtest (maybe other hardware tests on live os I have lying around) and then the "slow and one service after another".

I've had the occasional crash / *something that makes the server stop working and responding to anything* a few times now, with some months in between and once I could identify some plugin (I think it was some GPU statistics?) when it happened more often. But now I've had to leave and the server went unresponsive twice in 2 weeks (Crashed Mar 28th, restarted on Apr 3rd, crashed on 5 and only managed after reseating the usb drive...) and it became unresponsive again after less than 3days. -> API lost connection, no pings got answered, Dockers and VM were unaccessible. I don't know whether it still did something, it was still powered on (fans running), but no new syslog entries. I - again - can't find anything telling me what caused it. In the syslog I could find the Parity Tuner Plugin spamming errors - because I had to reset the server to start it again and it then had the flags for automatic and manual parity check (although I didn't start it manually? Must be from the "crash") I'm adding the syslog from after the restart on Apr 3rd -> End Apr 5th, I only changed the hostname (now I know that is useless because it appears in the anonymized diagnostics) and where the warning "Parity Check Tuning: ERROR: marker file found for both automatic and manual check P" happened multiple times so it only appears once. Since I haven't really done any changes apart from updating docker and unraid, this is really bothering me. Steps I have planned: - run a full memtest (although the server has quite high utilization on ram/cpu, so I can't see why defective memory wouldn't have shown earlier...) If I can't figure out why this is happening (and I don't have IPMI to reset it remotely) I'm thinking of either running Unraid as VM on proxmox (migration might be easy or impossible... ) + unloading the most important services to a micro server (Nextcloud, Homeassistant) In terms of resetting, only easy solution I can up atm is power cycling with a remote contrallable power plug... (could hurt the hardware eventually, but then I can't see a cheap alternative... if I don't want to go for a pikvm or similar) syslog-192.168.2.101-shortened.log unraid-diagnostics-20240417-1828.zip

docker run -d --name='jDownloader2' --net='bridge' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e HOST_HOSTNAME="nas-mhmx" -e HOST_CONTAINERNAME="jDownloader2" -e 'UMASK'='000' -e 'UID'='99' -e 'GID'='100' -e 'CUSTOM_RES_W'='1600' -e 'CUSTOM_RES_H'='900' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:7808]/vnc.html?autoconnect=true' -l net.unraid.docker.icon='https://raw.githubusercontent.com/ich777/docker-templates/master/ich777/images/jdownloader.png' -p '7808:8080/tcp' -v '/mnt/user/appdata/jdownloader2/':'/jDownloader2':'rw' -v '/mnt/user/downloads/jdown':'/mnt/jDownloader':'rw' -v '/mnt/user/downloads/jdown':'/output':'rw,shared' --restart=unless-stopped 'ich777/jdownloader2' Sorry for the late reply, but I had no access to my server for a while -.- I don't think this will help you, because I did change the values after I noticed...

I'm stuck with my Jdownloader 2 Container, I noticed it stopped running / did not start, so I followed the pinned troubleshooting steps of removing Core.jar, JDownloader2.jar, tmp and update folders - no avail. When I try to start, I do get a "Server execution error" - nothing in the logs (that are accessible via the unraid UI) Then I uninstalled the app and reinstalled from Community Applications Store - it downloaded the image fresh, but still the same error: Execution error - Server error Edit: Something must've screwed with multiple containers, since they're all set to the same port o_O I noticed it wasn't the default port in the template when reinstalling, so I assumed it was the custom port I set last time - but nope.