jmbrnt

Ah, I'm headless so I'll work something out. I was unable to reach my GUI with my local IP. Weirdly though, I could get to it via Tailscale IP. I have now removed Tailscale for a bit to see if it becomes more stable.

Thanks, I manually removed the most recent plugin I had installed (gpu stats + intel gpu top) and we're back up and running, but it was quite an odd state, I've been using unraid for 9 years and never seen it do that before :) How can you reboot into safe mode from the CLI?

New Unraid (trial license) before I move over from my 'real' server. Basically this box has been going ok, but today Plex stopped respondng, I can't get to GUI even after a reboot. Containers all seemed to be running fine, although I couldn't get to their web front ends, much the same as GUI. The last thing I did, an hour or so before it became unreachable via webgui was install the gpu statistics plugin Attached diagnostics from prior to reboot. Any clues on what might be going wrong? From the logs I looked into there wasn't much of a smoking gun. Appreciate any help :) nasty-nas-diagnostics-20251010-2237.zip

I am using the non-VPN variant. I shifted back from binhex/arch-deluge:2.0.5-1-03 to binhex/arch-deluge and the problem persists (web-ui won't load). Log for interest Created by... ___. .__ .__ \_ |__ |__| ____ | |__ ____ ___ ___ | __ \| |/ \| | \_/ __ \\ \/ / | \_\ \ | | \ Y \ ___/ > < |___ /__|___| /___| /\___ >__/\_ \ \/ \/ \/ \/ \/ https://hub.docker.com/u/binhex/ 2022-11-02 07:56:58.033568 [info] Host is running unRAID 2022-11-02 07:56:58.072848 [info] System information Linux 9472e3bdb4e1 5.10.21-Unraid #1 SMP Sun Mar 7 13:39:02 PST 2021 x86_64 GNU/Linux 2022-11-02 07:56:58.123264 [info] OS_ARCH defined as 'x86-64' 2022-11-02 07:56:58.174845 [info] PUID defined as '99' 2022-11-02 07:56:58.286208 [info] PGID defined as '100' 2022-11-02 07:56:58.434978 [info] UMASK defined as '000' 2022-11-02 07:56:58.475525 [info] Permissions already set for '/config' 2022-11-02 07:56:58.539970 [info] Deleting files in /tmp (non recursive)... 2022-11-02 07:56:58.598229 [info] DELUGE_DAEMON_LOG_LEVEL defined as 'error' 2022-11-02 07:56:58.641334 [info] DELUGE_WEB_LOG_LEVEL defined as 'error' 2022-11-02 07:56:58.692460 [info] Starting Supervisor... 2022-11-02 07:56:59,459 INFO Included extra file "/etc/supervisor/conf.d/deluge.conf" during parsing 2022-11-02 07:56:59,459 INFO Set uid to user 0 succeeded 2022-11-02 07:56:59,465 INFO supervisord started with pid 6 2022-11-02 07:57:00,468 INFO spawned: 'deluge-script' with pid 74 2022-11-02 07:57:00,468 INFO reaped unknown pid 7 (exit status 0) 2022-11-02 07:57:00,482 DEBG 'deluge-script' stdout output: [info] Deluge config file already exists, skipping copy [info] Attempting to start Deluge... [info] Removing deluge pid file (if it exists)... 2022-11-02 07:57:00,482 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2022-11-02 07:57:01,427 DEBG 'deluge-script' stdout output: [info] Deluge process started [info] Waiting for Deluge process to start listening on port 58846...

Yep, I can confirm this too, webUI borked. I went back to 2.0.5-1-03 and it's ok. @binhex

Thanks - I am using the tshock one and that doesn't seem to be the case `Terraria Server v1.4.3.6` whereas it's up to 1.4.4.5 now (via https://terraria.fandom.com/wiki/Server#Downloads)

@ich777 is there something I need to do to update the tshock/terraria container to the most recent version of terraria? it's not currently allowing players to join as it's out of date

Thanks @JorgeB that;s very useful

Seems like my cache is dying - can you please help me plan out what to do? Log is flooded with these messages: BTRFS error (device loop2): parent transid verify failed on 148996096 wanted 1692344 Attached my diagnostics. I'l guessing I need to try and get everything off the cache and reformat it - are there some good steps for follow for that? Thanks unraid-2-diagnostics-20220513-1104.zip

Just wanted to say thanks to @ich777 - I put an old GTX 960 into my Dell R720 and now Plex transcoding is all being done so smoothly (particularly subtitled shows). Amazing instructions, all worked first time. Beautiful work.

Cool thanks, I got it working when I used the literal username in question in /home/*username*/upload

First up thanks @MarkusMcNugen for the efforts. In SFTP my goal is to share a directory from my unraid array with a friend. I create him a user and he can SFTP connect fine, but so far no amount of trial and error has successfully shared the files with him. What do I need to add to the container under Unraid to make this work? Say I wanted him to log in and see the content of my /mnt/users/videos dir? Cheers

Bit late to the party, But I am using the librenms/librenms version of the container from CA. Before starting the librenms container, create a new MariaDB container (I am using the linuxserver/mariadb one). Once that is loaded, use the CLI for that container to build your database, and allow access from another host: CREATE DATABASE librenms CHARACTER SET utf8 COLLATE utf8_unicode_ci; CREATE USER 'librenms'@'localhost' IDENTIFIED BY 'librenms'; CREATE USER 'librenms'@'%' IDENTIFIED BY 'librenms'; GRANT ALL PRIVILEGES ON librenms.* TO 'librenms'@'localhost'; GRANT ALL PRIVILEGES ON librenms.* TO 'librenms'@'%'; FLUSH PRIVILEGES; exit Now, when you configure the LibreNMS container, point the DBhost to be the IP of the container (in my case 192.168.0.196, the same IP as the unraid box itself, as I'm using bridged networks for the containers). After a couple of minutes you can open the LibreNMS GUI and get cracking.

Thanks @broadcastthebadger - this gives me some hope at 1:40am... I have recently brought my (encrypted) Unraid server across the ocean, and when it came time to boot up I was getting all sorts of kernel panic messages (about sync..). Doing it all from the iDrac terminal made gathering logs tricky, but I thought I would try and recover my config files from the existing USB stick (which had been working well for 2+ years) and go with a new stick.. Several hours later and still no boot - the closest I got to that nice blue syslinux menu was using UEFI, which doesn't seem to work with my Dell R720.. Can you share what settings you used in Rufus to make your bootable stick? Tonight I've tried: - 3 different USB (2, 2, 3) sticks - UEFI/BIOS - Creating the sticks using the Unraid tool on Mac, PC - Creating the stick by hand using Mac, PC, Linux - Booting the stick in another PC (which worked) - Drinking

Hey @A75G - thanks for all your efforts. I have installed your LibreNMS container, and setup a MariaDB on the same host librenms/librenms/librenms all the way down - but it can never connect. The log doesn't give much away - any tips for getting this to work? The IPs/ports etc all match.

Ah well at least the symptom makes sense. Not so sure if the cause does. I could understand a restart or reload... cheers

Bit of a weird issue for me. I started up Dynamix' Wireguard plugin, following the blogpost on Unraid.net. Worked perfectly with my Macbook, using the `Remote Tunneled Access` mode. Great. Then I went and added another peer (I wanted to use my phone too). After clicking 'Add peer' and generating the keys, I clicked Apply or whatever and... Lost access. No go at all. Can't even connect back to the server to undo what I did. Is that expected behavior? Note, I only generated new keys for the new peer, so I didn't expect to get locked out. Any suggestions welcomed - and thanks for building such a simple/great system!

Something seems really broken with this container, or at least the job F@H is sending me. It folds for a couple of seconds, then dies. Log below. 21:21:13:WU00:FS00:0xa7:ERROR:------------------------------------------------------- 21:21:13:WU00:FS00:0xa7:ERROR:Program GROMACS, VERSION 5.0.4-20191026-456f0d636-unknown 21:21:13:WU00:FS00:0xa7:ERROR:Source code file: /host/debian-stable-64bit-core-a7-avx-release/gromacs-core/build/gromacs/src/gromacs/mdlib/domdec.c, line: 6902 21:21:13:WU00:FS00:0xa7:ERROR: 21:21:13:WU00:FS00:0xa7:ERROR:Fatal error: 21:21:13:WU00:FS00:0xa7:ERROR:There is no domain decomposition for 25 ranks that is compatible with the given box and a minimum cell size of 1.37225 nm 21:21:13:WU00:FS00:0xa7:ERROR:Change the number of ranks or mdrun option -rcon or -dds or your LINCS settings 21:21:13:WU00:FS00:0xa7:ERROR:Look in the log file for details on the domain decomposition 21:21:13:WU00:FS00:0xa7:ERROR:For more information and tips for troubleshooting, please check the GROMACS 21:21:13:WU00:FS00:0xa7:ERROR:website at http://www.gromacs.org/Documentation/Errors 21:21:13:WU00:FS00:0xa7:ERROR:------------------------------------------------------- 21:21:18:WU00:FS00:0xa7:WARNING:Unexpected exit() call 21:21:18:WU00:FS00:0xa7:WARNING:Unexpected exit from science code 21:21:18:WU00:FS00:0xa7:Saving result file ../logfile_01.txt 21:21:18:WU00:FS00:0xa7:Saving result file md.log 21:21:18:WU00:FS00:0xa7:Saving result file science.log 21:21:18:WU00:FS00:FahCore returned: INTERRUPTED (102 = 0x66) 21:22:13:WU00:FS00:Starting 21:22:13:WU00:FS00:Removing old file './work/00/logfile_01-20200326-205104.txt' 21:22:13:WU00:FS00:Running FahCore: /app/usr/bin/FAHCoreWrapper /config/cores/cores.foldingathome.org/v7/lin/64bit/avx/Core_a7.fah/FahCore_a7 -dir 00 -suffix 01 -version 705 -lifeline 258 -checkpoint 15 -np 31 Edit: talking to someone with more F@H experience, this seems like a dud WU. Will re-install the container.

Thanks Squid. I have 96 cores running this dang thing, didn't want to miss the boat

Anyone know how to force this to fold for covid-19? I have updated the container and no go...

Thanks for checking that. You can see which driver your NICs have under Settings > Network Settings > Interface rules. The driver name is in parentheses. I am wondering if there are variants (or older/incompatible versions) of the driver on Unraid in use that don't play nice with a Centos VM. Narrowing down the problem in lieu of any advice from the Unraid developers might take a few shots. For the record, I don't think it's a problem with Unraid 6.8.2 or Centos, as it works flawlessly for me, without needing to pass through the PCI device - simply setting the VM to use br0 works. Would be great to solve this problem as it must be affecting a few people.

The driver I'm referring to is on the unraid host system, nothing to do with the VM. My theory based on comparing a working and non-working system was due to a difference in broadcom drivers seen in Unraid OS itself. I also suggested some XML edits you were asking about to try, did they have any effect?

Hi @eds I have just had a look at this issue. The XML for my test Centos 8 VM I just fired up (on Unraid 6.8.1)... <interface type='bridge'> <mac address='52:54:00:e0:a3:3c'/> <source bridge='br0'/> <target dev='vnet1'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> That is the default, generated by Unraid on my behalf (I selected br0 is my NIC to pass to the VM, as per usual). As itimpi said, there are a variety of NIC models you can use in kvm/qemu.. I have tested the following as working: - e1000, virtio, vmxnet3 You just edit the model type='X' parameter above. In my experience, e1000 has the best compatibility, vmxnet3 has the best performance (ony matters 10G and above, again, in my experience). Are you able to try making that change and see how it goes? Edit - note, it's worth mentioning my server is a Dell R730, using 1G broadcom based NICs. I am using the tg3 driver (as seen under settings>network settings> interface rules). It might be worth checking which driver you have. I know a chap with bnx2 drivers and he has trouble with Centos VMs too... Upgrading the variant of driver your NIC uses might be a solution in itself.

The port settings in the delugevpn container are automatically set by binhex's code (check supervisord log to see the magic happening) - you don't need to set them. Incoming port is the important one from a port forwarding perspective, you're likely to see this change when you restart the container. Outgoing doesn't matter so much (for some reason mine has just jumped from seeding around 0.1Kbit/s to 250Kbit/s so I have no idea what's going on

Yeah sorry, as I said that didn't work. You can probably spend time to get wget working in the container - but it might not be worth it. It ~might~ be a different type of encryption being used in the application versis the .ovpn file that deluge container is using - binhex has a help thread where he mentions selecting a different algorithm if it's supported by the vpn endpoint, but I've not got any experience with that. When you change location (or even reload the container) you will get a new port and likely a new IP. Binhex is very clever and his container automatically negotiates and configures this port inside deluge for you (as long as you're using PIA) - so you don't need to touch it.