Progeny42

Unraid version is 6.12.4. I've created a new Ubuntu 20.04 VM, and I'm passing through one of the shares using the Unraid Share Mode Virtiofs Mode. I've mounted it in the VM as follows in the /etc/fstab. Repository /mnt/repository virtiofs defaults 0 0 If I make a change to a file on the Repository network share on my Windows desktop computer, and save the change, the updated file is not immediately available within the VM. For example, I could add a new line to the end of a file, and if I 'cat' or 'nano' the file in the VM, the change is not there. After randomly using 'cat', 'nano' or 'ls' on the /mnt/repository directory for a minute or so, the changes eventually appear, though I'm not convinced any of those commands are doing anything to help. If I watch an example file using 'watch -n1 cat /mnt/repository/test_file.txt', and change the contents on my remote machine, I've still not seen the changes appear for over 2 minutes now. Is this an artifcat of using virtiofs? In the past, I've used 9p, and not had the same Issue. I've not tried that yet to see if is any better. ---- Update In the event anyone else also suffered this issue, I've reverted to using 9p pass through instead. In the VM settings on Unraid, I changed the Unraid Share Mode to 9p Mode, and updated the /etc/fstab by replacing "virtiofs" with "9p". This now resolves my issue.

The latest version (2023.09.25.68.main) has created a regression whereby Datasets with spaces are no longer being detected by the plugin. I had installed version 2023.07.04 for the first time, and they did show, as per the release notes. Additionally, with destructive mode enabled, I'm unable to destory a Dataset with the plugin, and am presented with the error "Device or resource busy". However, if I run the command from the Unraid terminal (for example) zfs destroy tank/appdata/filebrowser it works fine

As of 7 hours ago, I'm getting the following alert pinged to me via email from Unraid: /bin/sh: line 1: 28292 Killed /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null This is occurring every 25-30 minutes or so. The Unraid GUI is broken a bit now too; I can navigate between pages, but the syslog won't load, sometimes the Main tab won't load areas, the Docker and VMs tab won't load at all, and I cannot update Plugins. The day before, Unraid became unresponsive around 1:00am, and was no longer displaying an output, so I had to hard reset it. It is currently finishing up the parity check it initiated due to this. It's obviously a dynamix plugin causing this issue, but not sure which one uses the "monitor" script. I have not added, updated or removed any plugins in over 4 weeks, so seems odd that this is occurring now. The only thing that has changed in my machine is I added some new sticks of RAM, but that was 2 weeks ago. The more I write this, the more it sounds like it's a hardware fault, and not software, seeing as the OS is running in RAM. Unfortunately, I tried to get Diagnostic logs, but it's hanging (it's been running for over an hour now). I've attached all of the Dyanmix plugins that I currently have. Running on Unraid 6.9.1. I'll try pulling the extra RAM I added, and guess I'll have to monitor it for a few weeks to see if this happens again.

I am also having issues as of late as identifed by the File Activity tool, where Nextcloud is accessing an /appdata_{instanceId} directory and /files_encryption directory under /mnt/diskX/Nextcloud. This is causing a few of my disks to remain spun up. This did not use to be an issue. I use Nextcloud as a target for Backup, so I cannot change the share to use the cache. The Container is correctly configured using /data => /mnt/user/Nextcloud and /config => /mnt/user/appdata/nextcloud

*Bump* If 9p is a bad way to mount a drive, then would anyone care to explain what the correct way is for best performance?

I reseated the LSI card, the breakout SAS to SATA cable, and the SATA Power cable to the HDD. I'm still having the same issues as described, with the same behaviour shown in the log etc.

Okay, I'll double check all the connections tomorrow. Apologies; Have attached them to this response if they are still necessary. I did some further investigation pending my hardware checks tomorrow; If when the drive is spun down (according to Unraid) I go to spin it up by selecting the grey circle on the Main tab, it "spins up" in 1 second. On the other hand, if I then spin it down, and then up again, each operation takes ~8 seconds. I've tried to demonstrate this in the Unraid terminal; If I issue a spindown command to a different disk that is spun down (not on the LSI card), using the time command, it takes 0.005s. If I then issue the same command to this HDD, /dev/sdc, it takes ~0.600s. Below is a snippet of the log again which shows my spindown command and the drive spinning itself up unbeknownst to Unraid. Each time the block starting with "attempting task abort! scmd(0000000016cce60b)" occurs, the drive is now spun up, as the spindown command will take ~0.6s. I did this twice in succession at 22:53:27 and 22:54:05. If I issue the command again quickly (at 22:54:10), the drive has not yet spun up, and the time for the operation is 0.003s, and there is no "Power-on or device reset occurred" message. Jan 1 22:52:38 Elysia kernel: sd 9:0:1:0: attempting task abort! scmd(0000000016cce60b) Jan 1 22:52:38 Elysia kernel: sd 9:0:1:0: [sdc] tag#2945 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Jan 1 22:52:38 Elysia kernel: scsi target9:0:1: handle(0x0009), sas_address(0x4433221104000000), phy(4) Jan 1 22:52:38 Elysia kernel: scsi target9:0:1: enclosure logical id(0x5842b2b057bb1000), slot(7) Jan 1 22:52:38 Elysia kernel: sd 9:0:1:0: task abort: SUCCESS scmd(0000000016cce60b) Jan 1 22:53:27 Elysia kernel: mdcmd (969): spindown 29 Jan 1 22:53:27 Elysia kernel: Jan 1 22:53:28 Elysia kernel: sd 9:0:1:0: Power-on or device reset occurred Jan 1 22:53:46 Elysia kernel: sd 9:0:1:0: attempting task abort! scmd(000000006a31cdd3) Jan 1 22:53:46 Elysia kernel: sd 9:0:1:0: [sdc] tag#1081 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Jan 1 22:53:46 Elysia kernel: scsi target9:0:1: handle(0x0009), sas_address(0x4433221104000000), phy(4) Jan 1 22:53:46 Elysia kernel: scsi target9:0:1: enclosure logical id(0x5842b2b057bb1000), slot(7) Jan 1 22:53:46 Elysia kernel: sd 9:0:1:0: task abort: SUCCESS scmd(000000006a31cdd3) Jan 1 22:54:05 Elysia kernel: mdcmd (970): spindown 29 Jan 1 22:54:05 Elysia kernel: Jan 1 22:54:06 Elysia kernel: sd 9:0:1:0: Power-on or device reset occurred Jan 1 22:54:10 Elysia kernel: mdcmd (971): spindown 29 Jan 1 22:54:10 Elysia kernel: Also, while the GUI shows the drive is spun down, it reports an average temperature of 35 C (which is the temperature of that drive) It only changes to a * when I then issue the spindown command elysia-diagnostics-20210101-2303.zip

My concern isn't the GUI so much as it is that the LSI card is keeping the drive spun up near constantly

Unraid Version: 6.8.3 LSI SAS 2008: Firmware: 20.00.07.00-IT Product ID: SAS9211-8i BIOS: 07.11.10.00 NVDATA: 14.01.00.08 I recently purchased the above LSI card to add additional SATA drives to my server. At the moment, it has 1 HDD and 1 SSD attached. For some reason, the HDD is being spun up, but Unraid does not know about it. Note I have 5 disks + 2 parity. The LSI attached drives are shown below: SCSI Devices: [9:0:0:0]disk ATA INTEL SSDSC2BF24 LH6i /dev/sdb 240GB [9:0:1:0]disk ATA WDC WD80EDAZ-11T 0A81 /dev/sdc 8.00TB I've attached the full syslog from Unraid, where the start of the log is when the new LSI card was installed. Here is a snippet from the logs showing this spinup behaviour (Disk 29 is the HDD attached to the LSI Card): Jan 1 10:25:34 Elysia kernel: mdcmd (881): spindown 0 Jan 1 10:25:35 Elysia kernel: mdcmd (882): spindown 1 Jan 1 10:25:35 Elysia kernel: mdcmd (883): spindown 2 Jan 1 10:25:36 Elysia kernel: mdcmd (884): spindown 3 Jan 1 10:25:36 Elysia kernel: mdcmd (885): spindown 4 Jan 1 10:25:37 Elysia kernel: mdcmd (886): spindown 5 Jan 1 10:25:37 Elysia kernel: mdcmd (887): spindown 29 Jan 1 10:26:12 Elysia kernel: sd 9:0:1:0: attempting task abort! scmd(000000007fcbcbd9) Jan 1 10:26:12 Elysia kernel: sd 9:0:1:0: [sdc] tag#435 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Jan 1 10:26:12 Elysia kernel: scsi target9:0:1: handle(0x0009), sas_address(0x4433221104000000), phy(4) Jan 1 10:26:12 Elysia kernel: scsi target9:0:1: enclosure logical id(0x5842b2b057bb1000), slot(7) Jan 1 10:26:12 Elysia kernel: sd 9:0:1:0: task abort: SUCCESS scmd(000000007fcbcbd9) As you can see, about 45 seconds after the spindown command, the disk gets spun up again, but Unraid does not show the disk as Active (presumbly because it looks at the last command it issues). I noticed this behaviour as the drive was constantly reporting Temperature statistics in Grafana, and I could hear it spin up. I'm entirely new to the world of SAS / HBA cards, and the above specs are those taken from the listing - I have not verified they are true (I'd have to look into how to do that). Does this look like a fault of the LSI card? Is this a Firmware issue? Thanks in advance elysia-syslog-20210101-1057.zip

@santiman717 Can you post a screenshot of the Container's configuration? (Remove or blur any emails or sensitive info)

I've been trialling Nextcloud as a cloud backup service for myself, and if successful, my family which live remotely. I'm using Duplicati to perform the backups, but that's not the point of this guide. The point is that when I backup files to Nextcloud, the Docker Image slowly fills up. I've never had it reach a point where the Image reaches 100%, but it's probably not a fun time. After searching the internet for hours trying to find anything, I eventually figured out what was required. For context, I'm running Nextcloud behind a Reverse Proxy, for which I'm using Swag (Let's Encrypt). Through trial and error, the behaviour I observed is that when uploading files (via WebDAV in my case), they get put in the /tmp folder of Swag. Once they are fully uploaded, they are copied across to Nextcloud's /temp directory. Therefore, both paths need to be added as Bind mounts for this to work. What To Do Head over to the Docker tab, and edit Nextcloud and add a new Path variable: Name: Temp Container Path: /tmp Host Path: /mnt/user/appdata/nextcloud/temp Next edit the Swag (or Let's Encrypt) container, and add a new Path variable: Name: Temp Container Path: /var/lib/nginx/tmp Host Path: /mnt/user/appdata/swag/temp And that's it! Really simple fix, but no one seemed to have an answer. Now when I backup my files, the Docker image no longer fills up.

Hmm not sure I can help you with that. It's not my software, I just made a template for it in unraid. Try contacting Snipe-IT directly about the issue

That'll likely be your problem. That App Key is too long. Make sure you use this command to generate a key in the Unraid terminal: openssl rand -base64 32 Then in the Container Edit menu, put: base64:yourappkeyhere

@Korshakov what is your App Key? This is the only time I've seen that issue.

@Dimtar Hey glad you figured it out. Yes, you will experience an error if the App Key is not valid as far as the Container is concerned. There's also nothing the log file to indicate that the App Key is the cause of the problem, so it's mostly just a trial an error thing. I'll add it to the original post as an update to warn people.

@argash Hey, glad to hear it helped someone! I've just checked CA, only saw my template in there, are you sure the second template isn't a previous install of yours? Out of interest, does your SMTP setup work?

Snipe-IT is an Asset Management System. This guide will help you to install it and get it running. Database Backend Installing MariaDB Snipe-IT requires MySQL or MariaDB as its database backend. We’ll be using MariaDB. Head over to Community Applications and pull MariaDB. I left the Host Port as 3306, but ensure it doesn’t conflict with any existing containers. If you change it you will need to use the custom value in the Snipe-IT configuration later. You’ll need to setup a root password in Key 3, and it must be at least 4 characters long. Now Apply to install the container. Creating a Database and User Snipe-IT requires that we setup a Database and User in preperation for the installation, so let’s do that. In the Docker tab, click on mariadb and select the Console option, which will open a Bash shell into the container. To login to the database, you’ll need to execute the following command: mysql -u root -p It will now ask for the password. This is the root password that we just configured in the template. To create a database, user and password for Snipe-IT, execute the following commands: CREATE DATABASE databasename; CREATE USER username IDENTIFIED BY 'password'; GRANT ALL ON databasename.* TO 'username'; Disabling Strict Mode Snipe-IT requires that Strict Mode is disabled for installation and setup. To ensure we put it back correctly after installation, we’ll be collecting the current values first. Execute the following command in the Bash shell to select all values. SELECT @@SQL_MODE; Copy all of the modes. Mine were; STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION Repeat this process for @@GLOBAL.SQL_MODE using the below command: SELECT @@GLOBAL.SQL_MODE; Now to disable Strict Mode, execute the following two commands: SET @@SQL_MODE = ''; SET @@GLOBAL.SQL_MODE = ''; Installing Snipe-IT I’ve put together a template for Snipe-IT in Community Applications, so it should just be a process of filling out the required values. Head over to Community Applications and search for snipe-it, and install it. There are quite a lot of options that need filling out, but they are all required. My configuration looks like this (fill out your own details where applicable) MySQL Database Name: databasename MySQL Username: username MySQL Password: password MySQL Database Host: 192.168.0.3 MySQL Database Port: 3306 SMTP Address: smtp.mail.yahoo.com SMTP Port: 465 SMTP From Address: [email protected] SMTP From Name: john doe SMTP Encryption: tls SMTP Username: [email protected] SMTP Password: your email password App Key: LEAVE THIS BLANK FOR NOW App URL: http://192.168.0.3:8087 App Timezone: Europe/London App Locale: en-GB Port: 8087 Ensure that Port and App URL use the same port number in the event that you change it. Ensure that MySQL Database Port is correct. Before hitting apply, we need to generate the App Key! Open the Unraid Terminal and run the following command: openssl rand -base64 32 This should produce something along the lines of: cbWIMLG/JSqLhEvZsRh7v37KfKL2CAwApn64oEEOTjI= Copy the value, and in the App Key field, enter base64:yourappkeyhere. Your App Key field should look like the following: base64:cbWIMLG/JSqLhEvZsRh7v37KfKL2CAwApn64oEEOTjI= Hit Apply to install the container. Setup Snipe-IT Once installed, go to the Docker tab and open the Web-UI for Snipe-IT. UPDATE: Whoops, looks like something went wrong. If you see the error "Whoops, looks like something went wrong.", this is likely an issue with your App Key (As experienced by myself and another member). Unfortunately, the Container log file won't say that the App Key is the problem. Go back in this guide, and ensure that your App Key is setup and valid. If the problem persists, check the Container log file for anything else, hopefully it will indicate why it's not loading properly. If everything went well, you should be presented with the Snipe-IT Pre-Flight page. Unfortunately, SMTP isn’t working for me, I’m not sure why, as I’ve setup SMTP using the same settings elsewhere. UPDATE: I've had confirmation that other email's are working, so it's likely just something to do with Yahoo accounts. Assuming all is green (except for Email), hit the Next: Create Database Tables button – BE PATIENT! I’m running this container on an SSD and it took nearly 2 minutes for this step to complete. Once complete, hit the Next: Create User button. At this point, fill out your details as appropriate, and then you should be presented with the User Interface. Re-Enabling Strict Mode We want to ensure that MariaDB maintains its integrity, especially if you currently / will use it for other uses. Open up a Bash shell for MariaDB again, and log in using the command from earlier. Once in, execute the following command, substituing your SQL_MODES save from earlier where applicable. My command looked like: SET @@SQL_MODE = 'STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'; Again, perform this command for @@GLOBAL.SQL_MODE. And that’s it, you should be all up and running! Now to spend hours inputting all my data…

[First time writing a guide, be nice!] I’m going to assume you already have Grafana, InfluxDB and Telegraf installed and running as Docker containers on your Unraid server. If not, I followed PanzerschreckGER‘s guide to get myself setup. Installing SNMP SNMP is a plugin originally developed by coppit, back in 2015. His original work is no longer maintained, and not compatible with the version of Unraid that I am using (6.8.3). In 2019, kubed_zero created a forked version which is compatible with Unraid 6.7.0. I’ll be using this. On Unraid, go to the Community Applications tab, and search for SNMP. Install the plugin. Once installed, you can now try the following command in the Unraid terminal. You’ll obviously need to do this to a device that supports the SNMP protocol. snmpwalk -v <snmp version> -c <community> <ip address> My command was the following: snmpwalk -v 2c -c public 192.168.0.5 If you see a lot of data fly past, everything is setup correctly and ready to go. I’m using a MikroTik CRS305-1G-4S+ Switch, which uses IF-MIB, SNMPv2-MIB, BRIDGE-MIB and MIKROTIK-MIB. If you are familiar with programming jargon, a MIB is effectively an object which stores multiple properties. Using the snmpwalk command, I can see I have access to the IF-MIB and SNMPv2-MIB objects. Therefore I can pull any information from them. I imagine the BRIDGE-MIB and MIKROTIK-MIB databases would have to be installed seperately. Definitions of what properties are available in IF-MIB and SNMPv2-MIB can be found found here and here. Enabling SNMP in Telegraf Navigate to the /appdata/telegraf directory and open up the telegraf.conf file. Uncomment the [[inputs.snmp]] section. Add agents as necessary. I added my network switch which I used to test the snmpwalk command. agents = ["udp://192.168.0.5:161"] Uncomment timeout, version, community, retries and max_repetitions. I left these at the default values. I used the Telegraf Documentation as a guide to setting up my configuration file. Here is a copy of my [[inputs.snmp]] configuration section. # Retrieves SNMP values from remote agents [[inputs.snmp]] ## Agent addresses to retrieve values from. ## example: agents = ["udp://127.0.0.1:161"] ## agents = ["tcp://127.0.0.1:161"] agents = ["udp://192.168.0.5:161"] # Timeout for each request. timeout = "5s" # SNMP version; can be 1, 2, or 3. version = 2 # SNMP community string. community = "public" # Number of retries to attempt. retries = 3 # The GETBULK max-repetitions parameter. max_repetitions = 10 ## SNMPv3 authentication and encryption options. ## ## Security Name. # sec_name = "myuser" ## Authentication protocol; one of "MD5", "SHA", or "". # auth_protocol = "MD5" ## Authentication password. # auth_password = "pass" ## Security Level; one of "noAuthNoPriv", "authNoPriv", or "authPriv". # sec_level = "authNoPriv" ## Context Name. # context_name = "" ## Privacy protocol used for encrypted messages; one of "DES", "AES" or "". # priv_protocol = "" ## Privacy password used for encrypted messages. # priv_password = "" ## Add fields and tables defining the variables you wish to collect. This ## example collects the system uptime and interface variables. Reference the ## full plugin documentation for configuration details. [[inputs.snmp.field]] oid = "RFC1213-MIB::sysUpTime.0" name = "uptime" [[inputs.snmp.field]] oid = "RFC1213-MIB::sysName.0" name = "source" is_tag = true [[inputs.snmp.table]] oid = "IF-MIB::ifTable" name = "interface" inherit_tags = ["source"] [[inputs.snmp.table.field]] oid = "IF-MIB::ifDescr" name = "ifDescr" is_tag = true [[inputs.snmp.table]] oid = "IF-MIB::ifXTable" name = "interface" inherit_tags = ["source"] [[inputs.snmp.table.field]] oid = "IF-MIB::ifDescr" name = "ifDescr" is_tag = true This configuration will setup two new measurements; snmp and interface. You’ll notice I’m using IF-MIB::ifTable and IF-MIB::ifXTable as [[inputs.snmp.table]]. According to RFC2863: I used both to collect as much information as possible. Now save the telegraf.conf file & restart the Telegraf container. Accessing the Data in Grafana Now in Grafana, you can access the data as shown below in some examples. Uptime Using the snmp measurement, and filtering on source, you can obtain the uptime field. Interface Statistics Remaining fields will be in the interface measurement. You can filter on just source, or a particular interface of it.

Old thread, but maybe someone else will stumble across it in the future. I was looking at how to do this myself, and also struggled to find an exact guide. So, I put one together myself on my self-hosted blog. Hope it helps someone!

Thanks for the swift reply. I had a feeling that line in the patch notes may have been the cause. I'll likely downgrade then, as I don't desperately require anything from 6.8.2.