air_marshall

sde extended SMART attached GUI reports completed without error tower-smart-20240326-2039.zip

Ok, extended sde SMART test is running. Will post results. Same for sdj, the disc I replaced in the array. Any ideas why there is such a gap in my logs? syslog-previous ends Mar 21 12:30:57. Any place else I can go looking for them? Log seems to be flooded with an nvidia error that I've not seen before!

Started 22 Mar 1051 Finished 22 Mar 2254 No reboot or power cycle since! Data-Rebuild 2024-03-22, 22:53:15 (Friday) 4 TB 12 hr, 2 min, 49 sec 92,2 MB/s OK 41

Hi Guys, Long story short, had some 'thermal management' issues in my 'comms room' that may have started to push some of my older drives closer to EOL. Drive sdj threw a couple of SMART errors so set about replacing that one first with a pre-cleared 4TB drive sdi that was pre-cleared. During rebuild of data drive sde threw 41 read errors which translated to 41 data errors with the rebuild. Last Parity check without errors was 07 Mar 24. See attached diagnostics. sdj still attached to machine and hasn't been touched since removing from the array. Data on that drive is largely expendable. Non-expendable is backed up elsewhere. I have another 4TB waiting to be pre-cleared that is available for either replacement of another drive or adding to the array. What are my next steps before I make this situation worse..... TIA tower-diagnostics-20240326-0923.zip

Good thinking. Done. First reboot from freshly prepared and restored stick has given the same result. Server GUI not accessible. Shares not mounted. SSH available. Looks like USB is read-only again. root@Tower:~# diagnostics mkdir: cannot create directory ‘/boot/logs’: Input/output error Starting diagnostics collection... tail: cannot open '/boot/bz*.sha256' for reading: No such file or directory sed: can't read /tower-diagnostics-20230829-0942/config/go.txt: No such file or directory done. ZIP file '/boot/logs/tower-diagnostics-20230829-0942.zip' created. Last lines of syslog using: Aug 29 09:42:42 Tower kernel: FAT-fs (sda1): Directory bread(block 30620) failed Aug 29 09:42:42 Tower kernel: FAT-fs (sda1): Directory bread(block 30621) failed Aug 29 09:42:42 Tower kernel: FAT-fs (sda1): Directory bread(block 30622) failed Aug 29 09:42:42 Tower kernel: FAT-fs (sda1): Directory bread(block 30623) failed Aug 29 09:42:42 Tower kernel: FAT-fs (sda1): Directory bread(block 30624) failed Aug 29 09:42:42 Tower kernel: FAT-fs (sda1): Directory bread(block 30625) failed Aug 29 09:42:42 Tower kernel: FAT-fs (sda1): Directory bread(block 30626) failed Aug 29 09:42:42 Tower kernel: FAT-fs (sda1): Directory bread(block 30627) failed Does this mean the USB is bad OR files in the USB config folder are corrupted? Diagnostics file attached from last shutdown before erasing and reinstalling usb. USB 2 port is in use. Best path forward at this point? tower-diagnostics-20230829-0914-shutdown.zip

Almost everytime I reboot/shutdown my server comes back-up with no GUI, no shares mounted. SSH is available and 'diagnostics' command results is a 'directory' doesn't exist error. USB drive chkdisk repair results in a successful boot. Diagnostics file is attached - I believe this one was captured automatically during post Tip and Tweaks install. TL;DR Server was off for c12 months during our house renovation. Upon reboot I've had multiple issues. First seemed to be related to docker not being terminated on array stop/reboot/shutdown. I found the forum post, used the commands to stop and then was able to clean reboot/shutdown. Server upgraded to latest stable. I set-about reformatting my cache to ZFS using spaceinvader video. Created a pool, but on copying back to the cache pool 1 of the drives had significant ATA issues, that drive eventually disappeared (I suspect went bad, but I've now pulled the SATA cable on it). So back to a single drive cache. Current situation is as above. I've carried out most suggestions from the 'Unclean Shutdown Thread", docker is disabled, no VMs, Tips & Tweaks plugin is installed to capture diagnostics on shutdown and time-outs set at 7 mins. There isn't a delay in unmounting drives however I feel like something is hanging on reboot/shutdown that results in the usb drive being mounted "read-only" on almost every reboot. Fixed by pulling the usb and doing a repair in windows but obviously not sustainable. Any/All help is much appreciated. I'm a long time unraid user and these are the first stability issues i've experienced. TIA tower-diagnostics-20230827-1032.zip

Thanks again @JorgeB, given time and case constraints I'll shrink the array for now and investigate further at another time. PITA, that'll be 3 drives I've had to drop in as many months since my re-casing project 😞

I had to drop disk1 because it failed a whilte ago and I shrank the array.

Woes continue. Firstly I re-manufactured the sata power cables to this bank of drives as I didn't like them. Connected it back up, did a short SMART test, rebuilt to same drive. That night same drive disabled at 01:40am. Then I switched the SAS port it was on, rebuild to same disk, then that night the same drive disabled at 01:42am. WTF is going on here. Happy to accept the drive might be bad despite passing SMART tests, but disabling itself at such consistent times I don't believe is just a co-incidence.... Latest diagnostics attached but I doubt it tell us anything new. Shall i just give up and remove the drive? tower-diagnostics-20210212-2340.zip

# Generated docker monitoring schedule: 10 0 * * 1 /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php check &> /dev/null # Generated system monitoring schedule: */1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null # Generated mover schedule: 40 3 * * 5 /usr/local/sbin/mover &> /dev/null # Generated parity check schedule: 0 0 1 * * /usr/local/sbin/mdcmd check NOCORRECT &> /dev/null # Generated plugins version check schedule: 10 0 * * 1 /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null # Generated Unraid OS update check schedule: 11 0 * * 1 /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null # Generated cron settings for docker autoupdates 0 0 * * 0 /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1 # Generated cron settings for plugin autoupdates 0 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1 # CRON for CA background scanning of applications 0 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1 # Generated ssd trim schedule: 0 2 * * 1 /sbin/fstrim -a -v | logger &> /dev/null # Generated system data collection schedule: */1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Any clues?

Here is the Cron output Linux 4.19.107-Unraid. root@Tower:~# crontab -l # If you don't want the output of a cron job mailed to you, you have to direct # any output to /dev/null. We'll do this here since these jobs should run # properly on a newly installed system. If a script fails, run-parts will # mail a notice to root. # # Run the hourly, daily, weekly, and monthly cron jobs. # Jobs that need different timing may be entered into the crontab as before, # but most really don't need greater granularity than this. If the exact # times of the hourly, daily, weekly, and monthly cron jobs do not suit your # needs, feel free to adjust them. # # Run hourly cron jobs at 47 minutes after the hour: 47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null # # Run daily cron jobs at 4:40 every day: 40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null # # Run weekly cron jobs at 4:30 on the first day of the week: 30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null # # Run monthly cron jobs at 4:20 on the first day of the month: 20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null 0 1 * * 2 /usr/local/emhttp/plugins/ca.backup2/scripts/backup.php &>/dev/null 2>&1 root@Tower:~# Any clues?

@JorgeB Thanks for the reply, as always. I haven't yet done what you suggested as the box is hard to get to and I have to empty a cupboard before even attempting to open it up. In the meantime I rebuilt to the same disk. Alas it disabled itself again the next night! However, what I've noticed is that all 3 of the error states have occurred at almost the same time... 20 JAN 01:17 - Tower: Alert [TOWER] - Disk 2 in error state (disk dsbl) SAMSUNG_HD103SJ_S2C8J9GZA00505 (sdl) 22 JAN 01:20 - Tower: Alert [TOWER] - Disk 2 in error state (disk dsbl) SAMSUNG_HD103SJ_S2C8J9GZA00505 (sdl) 24 JAN 01:22 - Tower: Alert [TOWER] - Disk 2 in error state (disk dsbl) SAMSUNG_HD103SJ_S2C8J9GZA00505 (sdl) This can't be a coincidence. Log attached from the latest error. Any clues as to what the server is doing at this time every night? Shouldn't be Mover, CA AppData Backup or SSD Trim. tower-diagnostics-20210125-1422.zip

Disk 2. Twice this week this drive has been disabled. Both Diagnostics attached. Passes an extended SMART test, can't see any errors in the log apart from: Jan 22 00:02:35 Tower kernel: sd 6:0:3:0: [sdl] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 The first time it showed an irrationally high number of "Reads" as can be made out in the screenshot below (sorry about the red filter). First time, whilst it was disabled I copied the emulated data to another drive, whilst running an extended SMART. On passing the SMART I re-built to the same drive (note there was little to rebuild as a moved it off). 2 evenings later the same disk goes down - albeit without the ridiculous number of reads. Drive is attached to and LSI 8 port card. 3 other drives are on the same 4 sata to sas cable. Been like this for 6-8 weeks without any issues (on these drives/controller at least). Expert Opinion please? tower-diagnostics-20210122-1019.zip tower-diagnostics-20210120-0351.zip

Thanks @JorgeB. I'll still have to rebuild the disk right? No way to avoid doing that? I'll replace the power cable. I could also put it on a different controller / port and see if it re-occurs at a later date. No critical data on it.

Having rebuilt to the same disk for disk5 and removing disk1 from the array all has been stable and fine for a couple of weeks. A parity check has been completed since too, after parity rebuild. Today, when again the server was seemingly doing very little I received an alert of read errors on the same disk as before, disk5. It's now back to the disabled status. Here is a diagnostics report. I have NOT rebooted the server or done anything else this time so hopefully I can get some more pointed assitance. I note this from the Disk Log Information from the disk: Dec 7 21:50:59 Tower kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 7 21:50:59 Tower kernel: ata1.00: failed command: READ DMA EXT Dec 7 21:50:59 Tower kernel: ata1.00: cmd 25/00:00:78:f9:37/00:01:ff:00:00/e0 tag 14 dma 131072 in Dec 7 21:50:59 Tower kernel: ata1.00: status: { DRDY } Dec 7 21:50:59 Tower kernel: ata1: hard resetting link Dec 7 21:51:03 Tower kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Dec 7 21:51:03 Tower kernel: ata1.00: configured for UDMA/133 Dec 7 21:51:03 Tower kernel: ata1: EH complete Dec 11 04:46:44 Tower kernel: ata1: link is slow to respond, please be patient (ready=0) Dec 11 04:46:49 Tower kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Dec 11 04:46:49 Tower kernel: ata1.00: configured for UDMA/133 Dec 11 08:39:15 Tower kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 11 08:39:15 Tower kernel: ata1.00: failed command: READ DMA EXT Dec 11 08:39:15 Tower kernel: ata1.00: cmd 25/00:08:d0:cf:11/00:00:fb:00:00/e0 tag 19 dma 4096 in Dec 11 08:39:15 Tower kernel: ata1.00: status: { DRDY } Dec 11 08:39:15 Tower kernel: ata1: hard resetting link Dec 11 08:39:21 Tower kernel: ata1: link is slow to respond, please be patient (ready=0) Dec 11 08:39:25 Tower kernel: ata1: COMRESET failed (errno=-16) Dec 11 08:39:25 Tower kernel: ata1: hard resetting link Dec 11 08:39:31 Tower kernel: ata1: link is slow to respond, please be patient (ready=0) Dec 11 08:39:35 Tower kernel: ata1: COMRESET failed (errno=-16) Dec 11 08:39:35 Tower kernel: ata1: hard resetting link Dec 11 08:39:41 Tower kernel: ata1: link is slow to respond, please be patient (ready=0) Dec 11 08:40:10 Tower kernel: ata1: COMRESET failed (errno=-16) Dec 11 08:40:10 Tower kernel: ata1: limiting SATA link speed to 3.0 Gbps Dec 11 08:40:10 Tower kernel: ata1: hard resetting link Dec 11 08:40:15 Tower kernel: ata1: COMRESET failed (errno=-16) Dec 11 08:40:15 Tower kernel: ata1: reset failed, giving up Dec 11 08:40:15 Tower kernel: ata1.00: disabled Dec 11 08:40:15 Tower kernel: ata1: EH complete Dec 11 08:40:15 Tower kernel: sd 1:0:0:0: [sdb] tag#20 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=0x00 Dec 11 08:40:15 Tower kernel: sd 1:0:0:0: [sdb] tag#20 CDB: opcode=0x88 88 00 00 00 00 00 fb 11 cf d0 00 00 00 08 00 00 Dec 11 08:40:15 Tower kernel: print_req_error: I/O error, dev sdb, sector 4212248528 Dec 11 08:40:23 Tower kernel: sd 1:0:0:0: [sdb] tag#23 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=0x00 Dec 11 08:40:23 Tower kernel: sd 1:0:0:0: [sdb] tag#23 CDB: opcode=0x8a 8a 00 00 00 00 00 fb 11 cf d0 00 00 00 08 00 00 Dec 11 08:40:23 Tower kernel: print_req_error: I/O error, dev sdb, sector 4212248528 When I was removing disk1 I took the opportunity to check and replace and re-route the sata cable for disk5. When visiting the Disk 5 Settings page the system is unable to read SMART attributes or Disk Capabilities, it also cannot be spun up. So it seems it's also dropped offline on the controller. tower-diagnostics-20201211-1238.zip

does docker-compose persist after reboot if you install it this way?

So I copied the emulated contents of disk5 off of the array onto a USB drive, no faults or errors occurred during this process. Having completed another extended SMART on disk5 without issue, combined with the fact there was no critical data on disk5 and me not having a spare disk or willing to spend on one I elected to rebuild to the same drive. This completed but with Errors concurrent with read errors from disc1. Why has this happened during the rebuild but not the copy of the same emulated data beforehand? Realistically how much data are we talking about as being corrupt? The latest diagnostics is attached detailing the sector errors, which I should add is now increasing with drive usage, so disk1 is definitely on the way out. Regarding data on disk1. If parity data is not part of the corrupted rebuild data on disk5 (i doubt there is any way of confirming this) I should be able to a) replace disk1 and rebuild without data corruption OR (if I am happy to shrink the array - which I am) unassign the disk1 and then copy the emulated data to another drive without data corruption; then proceed to shrink the array using the methods in the documentation. Should I run a non-correcting parity check first? There is some critical data on disk1, I have already copied that off to an external source with the drive still assigned and mounted, there were no errors during this copy process. tower-diagnostics-20201121-1408.zip

Ok thanks. I'm still trying to comprehend the situation here. So in all cases I should address disk5 first, regardless of the SMART errors on disk1? Errors during the rebuild of disk5 may result due to the SMART issues with disk1. Is that correct? Therefore if I retain disk5 in its current state I may be able to rescue data from it if required? If disk5 is currently mounted what is wrong with just copying all the data off it? Or is the data actually replicated from parity despite the mount? IF I get a successful rebuild of disk5 what do I need to do to address disk1 if I am happy to make it redundant.

Thank you for trying to help me. I think I'm struggling for drives in order to do this and having just spent on 2x4tb units I'm not inclined to get another. I have a spare 1tb 2.5 spinner that I can use and hasn't been used much, at the moment I've been using it externally to copy the critical data off disk1 and disk5. I also have a spare, slow, old 500gn 2.5 spinner that used to be my cache before I upgraded to an SSD for this purpose. I can probably also free up disk9 a new 4tb unit. Should attempt use ddrescue before attempting a rebuild to disk5? I will set about copying everything off disk5 now to the external 1tb I have in the meantime. At least then I have it so if there are any issues with a rebuild I might be in a better place.

I'm not sure what you mean. Disk 5 still shows as disabled but all data remains available due emulation. /mnt/disk5 is also listed and available There is only 300gb on disk 5 so I could transfer it off to a usb drive before attempting a rebuild to the same 4tb drive. Regarding issues with the rebuild, could these result due the SMART errors on disk1 that have also appeared? Thank you for trying to help me understand this situation.

Thanks @JorgeB The extended SMART passed ok and a did a parity swap followed by a rebuild and all was well. I now have bigger issues! See my other post! Eeeeeek

The Issue - 1 Disk Disabled and 1 Disk with SMART Errors.... Last night when for all intents and purposes the array wasn't doing anything I received the following push notifications: Tower: Warning [TOWER] - array has errors Array has 1 disk with read errors Tower: Alert [TOWER] - Disk 5 in error state (disk dsbl) WDC_WD40EZRX-00SPEB0_WD-WCC4ECKCLDV9 (sdb) Here's my first mistake, I didn't save the syslog before a reboot 😞 [idiot] I went to the webgui with the intention of checking disk 5 SMART errors or report. However, when clicking on the disk the system was unable to retrieve any attributes. The read error count was up at 80. I checked the "Disk Log Information" and it did list some errors, IIRC related to "ata hard resets and restarting the link". There was more than one. At this point I felt a reboot would be useful to see if the connection to the disk could be re-established. Upon reboot the disk was still disabled (red x) but connected and settings and reports were available. I ran a short SMART test, an extended test was run only a week or so prior (see background info below if you feel it's relevant!). It was and I believe remains clear. However, having read the wiki, I believe I can only re-enable that disk by rebuilding to it, is that correct? I saw the "Read Check" option was now available and believed the system was prompting me to do one, so I ran one. I now realise it's the only option available when a drive is disabled. Nevertheless, off it went. A few hours into the "Read Check" disaster struck with the following notification: Tower: Warning [TOWER] - array has errors Array has 1 disk with read errors Tower: Warning [TOWER] - reported uncorrect is 47 SAMSUNG_HD154UI_S1Y6JDWZ504027 (sdg) Tower: Warning [TOWER] - current pending sector is 18 SAMSUNG_HD154UI_S1Y6JDWZ504027 (sdg) WTF! But it hasn't disabled the disk (maybe because I already have a disk disabled - I don't know) I have since run a short and extended SMART test on that drive, the reports should be in the diagnostics file attached. I definitely has issues. I have been through what's on those drives, thankfully MOST of it, but not all, is non-critical data. I am in the process of copying off the array as much critical data I can, however I am unsure as to the data integrity state of the stuff on Disk 1, and Disk 5 is emulated. I know the array is currently unprotected What are my options here? What order do I need to go about things in order to minimise further risk to data The array is big enough to cope with dropping disk 1 altogether and I'm happy to shrink the array when all this is done. I'm just out of my depth here. Background Info I have recently completed a re-casing and upgrading project on my long time Unraid server. Earlier in the year I moved it from a HP N54L with a Mediasonic eSata Probox to a Lenovo P300 with said same Mediasonic eSata Probox. There were no issues with this phase, it was stable for a good 6 months without issue. In the last couple of weeks I re-cased and consolidated the whole thing into a Fractal Design Node 804 case, doing away with the Mediasonic eSata box. Again no real issues...APART FROM DROPPING A STACK OF 4 DRIVES ON THE FLOOR!!! ARHGHGHGHG. When I got the system back-up one of my 2TB drives had a hard mechanical failure from the drop. It was just loudly clicking under power and the system couldn't initialize the drive. It would eventually boot, obviously the drive was disabled but the array came up anyway. I had a new 4TB drive that I was adding to the array anyway so I pre-cleared it and attempted to rebuild the disabled drive to it, however it was slightly bigger than my 4TB parity (as that was a shucked drive) so I had to do a parity swap, followed by a data rebuild to the ex-parity drive. That drive is Disk 5, the first one in question here. After I had finished the data rebuild and run an extended SMART on the drive I left the array stable for the a couple of days in which time I believe it did a Parity Check finding 0 errors. I then set about converting 4 drives from rfs to xfs as I had a mixed array and wanted to consolidate. A lengthly process using UnBalance to clear them down and then reformatting and moving data about to clear the next one. Some of those drives were my oldest, so during that process probably had the most use they'd had for ages. Either way I got through it without too much bother. I then added an additional 4TB drive to the array to expand it further just the other day, which did involve moving some cables able, but the system had been up for a good few days for the issues described at the top of this post began. tower-diagnostics-20201119-2244.zip

Hi Guys and Girls, Looking for some advice/assistance here after a good thorough search on the issue. Long story short - I dropped a data disk spinner during a re-case and it seems the drive is now bad. Horrendous clicking on power, almost results in boot failure but we eventually get there and the drive is just missing. I haven't started the array since due fear of data loss given the findings below. It's highly likely that the drives are now plugged in to different controllers than there were before. I had 4 drives in a Mediasonic ProBox vis eSata from one of the PCIe controller cards. All drives are now internal via mobo sata and 2x differed PCIe Sata cards. However, the 2 drives in question are now on the mobo sata. No worries I thought, I have a new (pre-cleared) Toshiba X300 4TB for the array anyway so I'll just use that as a replacement drive instead. WRONG - Parity Drive must be biggest in system.... Wait, my parity drive is a WDC 4TB how can this be.... Anyway: Disk /dev/sdb: 3.65 TiB, 4000753476096 bytes, 7813971633 sectors Disk model: WDC WD40EZRX-00S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: F60C7E9F-92E4-4F57-86B1-1E6FB3E1DB77 root@Tower:~# hdparm -N /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 01 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 7813971633/1(1?), HPA setting seems invalid (buggy kernel device driver?) Disk /dev/sdf: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: TOSHIBA HDWE140 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x00000000 I'm just running an extended SMART on the WDC to check that, but want to seek guidance in the meantime. I'm assuming the WDC drive is short on the size / sector count based on a couple of reports from friends of their own 4TB drive size stats. As far as I can remember the WDC drive has never been on a gigabyte board but it may have been shucked from an external drive (I have no record of purchase though). What is my best option here to ensure no data loss and minimise downtime. 1. Accept the difference and carry out a parity swap 2. Investigate and try and fix the size difference, then add the Toshiba as the replacement drive for the failed unit (with you help) 3. Do something completely different and much more robust guided by all you smarter experts on this forum. First time facing this issue. Any more info required please let me know. TIA, Dan tower-diagnostics-20201107-1353.zip

I'm wondering this too. Looking at the master docker info you'd have to specify some more variable. I'm getting InnoDB and subsequent mysql errors on install so can't yet get it up. Everything stock as per the video apart from eth0 set to a static IP. root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='shinobi_pro' --net='eth0' --ip='192.168.50.200' -e TZ="Europe/London" -e HOST_OS="Unraid" -e 'TCP_PORT_8080'='8080' -e 'ADMIN_USER'='admin' -e 'ADMIN_PASSWORD'='password' -v '/mnt/disks/cctv/':'/opt/shinobi/videos':'rw,slave' -v '/mnt/user/appdata/shinobi_pro':'/config':'rw' -v '/mnt/user/appdata/shinobipro/database':'/var/lib/mysql':'rw' -v '/mnt/user/appdata/shinobipro/customautoload':'/opt/shinobi/libs/customAutoLoad':'rw' 'spaceinvaderone/shinobi_pro_unraid:latest' a8aa5c000266e29966658067e0cdc657becf86d88cac66537f73f209a2e4b39f The command finished successfully! Log result after install: Copy custom configuration files ... cp: cannot stat '/config/*': No such file or directory No custom config files found. Create default config file /opt/shinobi/conf.json ... Create default config file /opt/shinobi/super.json ... Create default config file /opt/shinobi/plugins/motion/conf.json ... Hash admin password ... MariaDB Directory ... Installing MariaDB ... Installing MariaDB/MySQL system tables in '/var/lib/mysql' ... 2019-12-28 12:46:49 0 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibdata1 failed with error 95 2019-12-28 12:46:49 0 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space 2019-12-28 12:46:49 0 [ERROR] InnoDB: Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again. 2019-12-28 12:46:49 0 [ERROR] Plugin 'InnoDB' init function returned error. 2019-12-28 12:46:49 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2019-12-28 12:46:50 0 [ERROR] Unknown/unsupported storage engine: InnoDB 2019-12-28 12:46:50 0 [ERROR] Aborting Installation of system tables failed! Examine the logs in /var/lib/mysql for more information. The problem could be conflicting information in an external my.cnf files. You can ignore these by doing: shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf You can also try to start the mysqld daemon with: shell> /usr/bin/mysqld --skip-grant-tables --general-log & and use the command line tool /usr/bin/mysql to connect to the mysql database and look at the grant tables: shell> /usr/bin/mysql -u root mysql mysql> show tables; Try 'mysqld --help' if you have problems with paths. Using --general-log gives you a log in /var/lib/mysql that may be helpful. The latest information about mysql_install_db is available at https://mariadb.com/kb/en/installing-system-tables-mysql_install_db You can find the latest source at https://downloads.mariadb.org and the maria-discuss email list at https://launchpad.net/~maria-discuss Please check all of the above before submitting a bug report at http://mariadb.org/jira

I believe they've moved it in the latest betas but that should also have been incorporated into the latest stable, which isn't available as part of this container yet (still!). I copied the dzvents from the windows install and fixed the permissions, seems to work fine for most things BUT I if I try to update a virtual temp sensor with a script I get reboots every minute - this can't be replicated by others on the domoticz forum, so can only assume it's something weird with the container... I'm debating moving it to a dedicated pi as my house gets more dependant on it and I need to ensure the WAF!