themaxxz

I also still have the same issue with version 2018.11.20

I suspect that adding 'missingok' option to /etc/logrotate.d/cache_dirs will prevent the error. Also the permissions of this file could be changed to 644.

Hi, I'd like to report a 'bug' of some sort. After skimming this thread, I thought this plugin could be usefull, so i installed it today on my unraid server (6.5.3). I decided to start slow and perform a disk by disk build. I first did a build on disk13, which only had 2 files. After that completed I started a build on disk3 with ~500 files. Currently still ongoing. (1 bunker process running related to disk3) I suddenly noticed the UI displayed a green check for all but one disk (disk9) under 'Build up-to-date'? I tracked back that it's populated from the file /boot/config/plugins/dynamix.file.integrity/disks.ini. After manually correcting (removing the not build disks) this file, the status in the UI reflects the correct situation. While trying to understand how this could happen, I was able to reproduce the issue, by clicking on the 'hash files' link on Tools/Integrity page. After clicking on this link all but one disk9 were re-added again to disks.ini file. What should be the correct format of this disks.ini file?

I just checked my server (6.5.3) and I also noticed the state was stopped. I started it again using the same procedure. (cache_dirs version: 2.2.0j)

I recently did this with an ubuntu live cd using the setblocksize program. As I'm not sure about the rules of posting external links, google for unsupported-sector-size-520.html

No the UPS never ran out of power. My condition is 5min on battery. The rest of the network stayed up and was still up when power returned after 30min or so. The server just completed a parity check (which I initiated) and everything checks out. I just didn't know about the shutdown time-out settings waiting for a graceful shutdown.

Ok, so it was an unclean shutdown in this case, and most likely due to having a too short timeout set. Thanks.

Thanks, indeed that is where I found the diagnostic file with the syslog.txt file from which I quoted the previous logging. But it's not clear to me how a clean or unclean shutdown logging should look like.

Perhaps a stupid question, but how can I see in the unraid-diagnostics file if there was an 'unclean' shutdown? This morning the ups 'nut' client initiated a shutdown 5min after being on battery as configured. May 9 04:09:06 unraid upsmon[5804]: UPS [email protected] on battery May 9 04:14:10 unraid upsmon[5804]: Signal 10: User requested FSD May 9 04:14:10 unraid upsmon[5804]: Executing automatic power-fail shutdown May 9 04:14:10 unraid upsmon[5804]: Auto logout and shutdown proceeding May 9 04:14:15 unraid shutdown[1509]: shutting down for system halt May 9 04:14:15 unraid init: Switching to runlevel: 0 The very last entry in the syslog.txt is May 9 04:15:48 unraid root: Generating diagnostics... So what does this mean exactly? In the meantime I also changed the timers as suggested.

Fix Common Problems reported an 'error' on my qbittorrent container with version 2017.10.15a. The last version reports an issue with my qbittorrent docker port not being the default 8080. But I actually had to change the port due to conflict with other docker as explained on https://hub.docker.com/r/linuxserver/qbittorrent/ Due to issues with CSRF and port mapping, should you require to alter the port for the webui you need to change both sides of the -p 8080 switch AND set the WEBUI_PORT variable to the new port. For example, to set the port to 8090 you need to set -p 8090:8090 and -e WEBUI_PORT=8090 I tried only changing (one side) the host port as suggested by Fix Common Problems, but this doesn't seem to work for this container.

I'm experiencing the same issue. It usually happens after a few days since the last restart.

Hi, I had the problem after updating to 2017.10.08 I guess I missed the update check for 2017.10.8a. I just updated to 2017.10.09 which seems to work. But the update plugin was missing the 'done' button.

Hi, I iust updated to last version, but I had to first stop and manually kill the remaining 'upsmon' processes to get it working again. Regards,

I also ran unraid virtualized on ESXi for years, but recently switched to running it BM and I'm now discovering and playing with the wonderful world of dockers. I still have another ESXi host to play with as well. As I was curious if I would be able to get this to work, I just was able to get esxi 6.0 update 1 installed on my unraid box as follows: - create a new VM using the coreos template (probably not really imported what template to choose) - make sure to select to provision 2 cpu cores (not threads) to the VM, just assigning 2 threads from a single core failed, with following error: CPU_CORES_ERROR: This host has [1] cpu core(s) which is less than recommended [2] cpu cores <cpu mode='host-passthrough'> <topology sockets='1' cores='2' threads='2'/> </cpu> - edit the xml and change 1) the network model from virtio to e1000 <model type='e1000'/> 2) storage disk to type 'sata' if not already the case <target dev='hdc' bus='sata'/> All other settings can be left default. During installation I did get a few warnings though: 1) HARDWARE VIRTUALIZATION is not a feature of the CPU, or is not enabled in the BIOS. -> I believe this is related to 'nested' virtualization setting as explained here https://allyourco.de/running-vmware-esxi-under-qemu-kvm/ I did not test, but probably following might work: - stop qemu - edit /etc/modprobe.d/kvm.conf as needed / explain on the previous site - unload / reload the kvm, kvm-intel modules - start qemu 2) UNSUPPORTED_DEVICES_WARNING: This host has unsupported devices [some pci device] -> I can probably go into the xml and remove the device, but it doesn't seem to cause an issue I did not test creating/running a VM inside this ESXi instance, since I believe this requires having the hardware virtualization enabled. I also don't know how well a VM will run. I have played with VMs running in nested ESXi running on ESXi and it ran well enough to play and run basic stuff.

Yup that also works.

There is no rush. I had a quick look at this myself and adding basename( ) around $excluded appears to work, at least when clicking the 'Backup now' button. In the /usr/local/emhttp/plugins/ca.backup/scripts/backup.php $rsyncExcluded .= '--exclude "'.basename($excluded).'" ';

Hi, Not sure what is going on, but it's not working for me. Now nothing gets excluded and everything gets backed up. Output from ps. root 13033 0.0 0.0 11640 2608 ? SN 23:15 0:00 sh -c /usr/bin/rsync -avXHq --delete --exclude "/mnt/user/docker.img" --exclude "/mnt/user/appdata/Community_Applications_VM_XML_Backup/" --exclude "/mnt/user/appdata/deluge/" --exclude "/mnt/user/appdata/EmbyServer/" --exclude "/mnt/user/appdata/mariadb/" --exclude "/mnt/user/appdata/plexmediaserver/" --exclude "/mnt/user/appdata/sabnzbd/" --exclude "/mnt/user/appdata/sickrage/" --exclude "/mnt/user/appdata/sonarr/" --exclude "/mnt/user/appdata/Sync/" --log-file="/var/lib/docker/unraid/ca.backup.datastore/appdata_backup.log" "/mnt/user/appdata/" "/mnt/user/unRaidBackup/[email protected]" > /dev/null 2>&1 root 13034 4.7 0.0 21244 6372 ? SN 23:15 0:04 /usr/bin/rsync -avXHq --delete --exclude /mnt/user/docker.img --exclude /mnt/user/appdata/Community_Applications_VM_XML_Backup/ --exclude /mnt/user/appdata/deluge/ --exclude /mnt/user/appdata/EmbyServer/ --exclude /mnt/user/appdata/mariadb/ --exclude /mnt/user/appdata/plexmediaserver/ --exclude /mnt/user/appdata/sabnzbd/ --exclude /mnt/user/appdata/sickrage/ --exclude /mnt/user/appdata/sonarr/ --exclude /mnt/user/appdata/Sync/ --log-file=/var/lib/docker/unraid/ca.backup.datastore/appdata_backup.log /mnt/user/appdata/ /mnt/user/unRaidBackup/[email protected] root 13035 0.1 0.0 89468 5004 ? SN 23:15 0:00 /usr/bin/rsync -avXHq --delete --exclude /mnt/user/docker.img --exclude /mnt/user/appdata/Community_Applications_VM_XML_Backup/ --exclude /mnt/user/appdata/deluge/ --exclude /mnt/user/appdata/EmbyServer/ --exclude /mnt/user/appdata/mariadb/ --exclude /mnt/user/appdata/plexmediaserver/ --exclude /mnt/user/appdata/sabnzbd/ --exclude /mnt/user/appdata/sickrage/ --exclude /mnt/user/appdata/sonarr/ --exclude /mnt/user/appdata/Sync/ --log-file=/var/lib/docker/unraid/ca.backup.datastore/appdata_backup.log /mnt/user/appdata/ /mnt/user/unRaidBackup/[email protected] root 13036 5.3 0.0 92192 3768 ? SN 23:15 0:05 /usr/bin/rsync -avXHq --delete --exclude /mnt/user/docker.img --exclude /mnt/user/appdata/Community_Applications_VM_XML_Backup/ --exclude /mnt/user/appdata/deluge/ --exclude /mnt/user/appdata/EmbyServer/ --exclude /mnt/user/appdata/mariadb/ --exclude /mnt/user/appdata/plexmediaserver/ --exclude /mnt/user/appdata/sabnzbd/ --exclude /mnt/user/appdata/sickrage/ --exclude /mnt/user/appdata/sonarr/ --exclude /mnt/user/appdata/Sync/ --log-file=/var/lib/docker/unraid/ca.backup.datastore/appdata_backup.log /mnt/user/appdata/ /mnt/user/unRaidBackup/[email protected] When selecting which folders to exclude, it now adds them with absolutes paths which is causing the exclusion to fail I think.

Hi @Squid I want to report a bug with CA Backup / Restore Appdata 2017.06.12 There seems to be a problem with long folder names, that get truncated with "..." when adding via the UI and so the exclude does not work. Sep 23 01:33:04 unraid root: Using command: /usr/bin/rsync -avXHq --delete --exclude "/mnt/user/docker.img" --exclude "Community_Applications_VM_XML_Bac..." --exclude "deluge" --exclude "EmbyServer" --exclude "mariadb" --exclude "plexmediaserver" --exclude "sabnzbd" --exclude "sickrage" --exclude "sonarr" --exclude "Sync" --log-file="/var/lib/docker/unraid/ca.backup.datastore/appdata_backup.log" "/mnt/user/appdata/" "/mnt/user/unRaidBackup/[email protected]" > /dev/null 2>&1 As you can see I wanted to exclude "Community_Applications_VM_XML_Backup", but it changes it into --exclude "Community_Applications_VM_XML_Bac..." and so it does not get excluded.

After switching my unRAID from virtualized to BM, and removing some usb keys that were giving 'errors', the layout is working again for me.

I just noticed by accident the same issue on my server. I saw 1 cpu pegged at 100% and it turned out to be cache_dirs. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7270 root 20 0 10760 3036 2048 R 100.0 0.0 795:53.95 cache_dirs lsof showed me # lsof |grep -i 7270 cache_dir 7270 root cwd DIR 0,2 380 2 / cache_dir 7270 root rtd DIR 0,2 380 2 / cache_dir 7270 root txt REG 0,2 1094752 298 /bin/bash cache_dir 7270 root mem REG 0,2 174816 2419 /lib64/ld-2.24.so cache_dir 7270 root mem REG 0,2 18436 2376 /lib64/libtermcap.so.2.0.8 cache_dir 7270 root mem REG 0,2 18808 2431 /lib64/libdl-2.24.so cache_dir 7270 root mem REG 0,2 2067512 2425 /lib64/libc-2.24.so cache_dir 7270 root 0r FIFO 0,8 0t0 59140270 pipe cache_dir 7270 root 1w CHR 1,3 0t0 1029 /dev/null cache_dir 7270 root 2w CHR 1,3 0t0 1029 /dev/null cache_dir 7270 root 6r REG 0,2 2727 6243 /usr/local/emhttp/update.htm cache_dir 7270 root 10r CHR 1,3 0t0 1029 /dev/null cache_dir 7270 root 63r FIFO 0,8 0t0 59140270 pipe Running unraid 6.3.5 This is the first time I had this problem, and the only thing that change in my environment is - upgrade of my docker plex image - switch my htpc to using LibreELEC (Krypton) v8.0.2 from gotham I have now reverted my htpc back to gotham and will see if the problem returns or not..

Just noticed the same thing on my server, running identical versions.

My parity check times in a mixed 2TB, 3TB, 6TB and 8TB archive drives. 22 hr, 55 min, 33 sec 96,9 MB/s 22 hr, 13 min, 11 sec 100,0 MB/s 22 hr, 58 sec 101,0 MB/s

Below the results of a preclear of a seagate 8TB shingled drive. Device Model: ST8000AS0002-1NA17Z Serial Number: xxxxxxx LU WWN Device Id: 5 000c50 0908f403f Firmware Version: AR15 User Capacity: 8,001,563,222,016 bytes [8.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5980 rpm Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Tue Apr 5 08:28:36 2016 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Preclear Successful^n... Total time 73:43:58^n... Pre-Read time 19:55:32 (111 MB/s)^n... Zeroing time 17:38:39 (125 MB/s)^n... Post-Read time 36:08:27 (61 MB/s) ================================================================== 1.15 = unRAID server Pre-Clear disk /dev/sdc = cycle 1 of 1, partition start on sector 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Verifying if the MBR is cleared. DONE = Disk Post-Clear-Read completed DONE Disk Temperature: 31C, Elapsed Time: 73:43:58 ========================================================================1.15 == ST8000AS0002-1NA17Z == Disk /dev/sdc has been successfully precleared == with a starting sector of 1 ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdc /tmp/smart_finish_sdc ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 114 100 6 ok 74771072 Seek_Error_Rate = 73 100 30 ok 21528871 Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-End_Error = 100 100 99 near_thresh 0 High_Fly_Writes = 99 100 0 ok 1 Airflow_Temperature_Cel = 69 77 45 near_thresh 31 Temperature_Celsius = 31 23 0 ok 31 Hardware_ECC_Recovered = 114 100 0 ok 74771072 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. root@Tower:/usr/local/emhttp# This was run on: unraid 6.1.6 Intel® Core™2 Duo CPU E6550 @ 2.33GHz 2GB ram ibm m1015 it mode