Progeny42

Members
  • Posts

    21
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Progeny42's Achievements

Newbie

Newbie (1/14)

7

Reputation

  1. 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.
  2. 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
  3. *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?
  4. 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.
  5. 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
  6. My concern isn't the GUI so much as it is that the LSI card is keeping the drive spun up near constantly
  7. 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
  8. @santiman717 Can you post a screenshot of the Container's configuration? (Remove or blur any emails or sensitive info)
  9. 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.
  10. 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
  11. 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
  12. @Korshakov what is your App Key? This is the only time I've seen that issue.
  13. @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.
  14. @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?
  15. 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: youremail@domain.com SMTP From Name: john doe SMTP Encryption: tls SMTP Username: youremail@domain.com 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…