dlandon

I've had the same issue. I disabled then re-enabled and got the apps working again. Haven't figured it out though. I think the Docker reloads the apps file structure and wipes out any changes made. When it does that the calendar and contacts directories in the apps directory are lost.

When I enable the calendar and contacts apps, they work just fine. If I do any kind of an update on the owncloud docker, the calendar and contacts apps directories get deleted. I then have to disable and re-enable the apps to get the directories re-created. I also have a files move app that I use that has to be re-loaded. Is there a better way to do this? I'm not sure how the docker files are updated, but if the files and directories in the apps directory that are not part of the distro could be respected, it would be better. Could the apps directory be moved to /mnt/cache/appdata/owncloud?

Ah yes. Thank you.

It worked. I just had to use the 64bit cpio package. installpkg /boot/packages/cpio-2.11-x86_64-2.txz

cpio works fine for v6. I did that to check out the updates before being able to install them on my server. The only difference if there ever was any would be in what compression level it uses. Ok. I'll give it a go.

I think that applies to v5 and not v6. I believe the packing/zipping mechanism has changed along the way in v6.

Can someone give me the method of unzipping bzroot and then zipping it back? I want to make some adjustments and save the changes for testing.

Ok. This is off the wall but I have a hunch. Disable UPS in the UPS settings and reboot. EDIT: Sorry, set Start APC UPS Daemon to no.

If I remember correctly, I used to see FTP file transfers in the Active Streams. I am not seeing these now. Did they used to be in the Active Streams?

All the script does is to set some parameters that affect a parity check and then start and stop a parity check. It's no different than running a parity check while Dockers and VMs are running. EDIT: You will get better results with Dockers and VMs stopped.

When I saw 'fatal', I thought it might be important. No problem, just wanted to see if it was really an issue. You once told me you run headless and can't see these messages. I use cache_dirs, but not the s3_sleep plugin.

I am seeing the following error message on the console when I boot up unRAID. "awk: fatal: cannot open file '/proc/mdcmd' for reading (No such file or directory)" I do not see this message when I reboot without plugins. It does show when plugins are loaded. The only plugins I have installed are Dynamix.

Powerdown offers some additional functionality like keeping a log history. http://lime-technology.com/forum/index.php?topic=31735.0

Powerdown has been and still is optional.

Nice!

I like that better. Thank you.

Pff, copied the wrong file to github ... wait for version 'c' No problem.

lol - Really!?! I'd actually prefer not to clear the cache, as this is better LOL, there is a version 'b' available now with the old cpu/mb icons resized to match the new fan icon. Agreed it looks fancier Just updated. Icons are still all the same in the /usr/local/emhttp/plugins/dynamix.system.temp/icons.

It looks like the temperature icons are the same as the fan indicator; all are fans.

I think the stats actually are more appropriate for the network utilization because it shows transmit and receive utilization in a nice graph. I believe bonienl set up the Dashboard to give a quick overview of the operation of the array, and I think he did a good job. The Dashboard is full of information and will only get overly busy to be useful if too much is added.

It's built into v6. Don't know about v5.

Yes you need to reboot unless you manually copy the DailyCacheTrim file to /etc/cron.daily. I don't remember the time the daily cron runs, but it is the early morning hours.

No. I think that trim might be a bit of a misnomer. Nothing is actually 'trimmed'. The number shown from the fstrim operation is the number of available bytes on the SSD. If no write operations have occurred between the two fstrim operations, then the number should be the same each time. Your output on each fstrim is the expected output. It looks like 60GB is available on your drive.

See below for a better implementation in unRAID 6. Currently unRAID does not support mounting cache drives with trim support. The trim support when mounting a drive is with the 'discard' switch. I have done some research on trim in Linux and there are those that believe that mounting a drive with trim may cause the drive to do too much work whenever a file is written to the drive and that once a day issuing a 'fstrim' will suffice. There is also some feeling that trim support when mounting a drive with a file system other that ext4 or BTRFS may not be ready for everyday use. Trim lets the SSD know what the OS using the drive thinks is available space on the drive. I have come up with a solution to support trim in unRAID until LT gets native trim support implemented for cache drives. There is currently an open feature request for trim support here: http://lime-technology.com/forum/index.php?topic=34409.msg320174#msg320174 Put the following file on your flash drive in the 'custom' directory. Trim script named 'DailyCacheTrim': # # Trim the SSD cache drive. # /sbin/fstrim -v /mnt/cache | logger go file entry: # # Set up daily SSD cache trim for unRaid cron. # fromdos < /boot/custom/DailyCacheTrim > /etc/cron.daily/DailyCacheTrim chmod +x /etc/cron.daily/DailyCacheTrim With the output piped to logger ('| logger') the output of the fstrim will show in the log. It simply displays the number of bytes trimmed. This is normal operation and is the correct output. The fromdos command is used to copy a file to Linux and insure the carriage return characters are removed and the output file is in Linux line feed format. It prevents issues with editing a file with an editor that is not Linux file format compatible. While the chmod +x may not be required, it just insures that the Linux file is executable. A better method for unRAID 6 Dynamix has a built in cron system that is a better way to implement the SSD Trim. Create a file called "trim.cron" and put it in the /flash/config/plugins/dynamix folder: 30 5 * * * /boot/custom/DailyCacheTrim &> /dev/null This will be added to the cron events when unRAID is booted, or you can manually start it without a reboot by: /usr/local/emhttp/webGui/scripts/notify cron-init Remove the trim entries from the go file and delete the DailyCacheTrim file from /etc/cron.daily. The SSD trim will be run at 5:30 AM daily. You can adjust this for a different time of day, or once an hour as you see fit. I think daily is sufficient.

Careful with calling it CLI Tools...... WOW! I DIDN'T EVEN THINK OF THAT! I TRULY DID AN LMAO WHEN I READ THAT JUST NOW! Yeah, I think "Power Tools" is probably good to avoid any less than desirable acronyms ;-) If you aren't careful, my parental controls will block me out.