Swarles

5. I believe the following should fix your issue. Go into terminal and paste the following: echo shareCacheEnabled='"yes"' >> /boot/config/share.cfg This will add share.cfg to your config with the appropriate line. Let me know if the mover tuning plugin works now. EDIT: I think the other way to have the file created would be to edit your global share settings. "Settings>Global Share Settings" 6. I believe mover.pid will only exist while the mover is running. I may be wrong though.

Damn, not had any issues with 6.12.X thus far which has been great. I did happen upon this thread suggesting to stop the array and dockers prior to upgrading to 6.12.3...but unfortunately I completely forgot and rebooted before doing that. Unfortunately the upgrade/reboot process resulted in an unclean shutdown for me. Only time I have experienced that. Remember to do ALL the steps everyone!

Could you provide some more info for which share you’re trying to use a hidden folder? From what I can see in your latest logs from diagnostics you have been using the “Move now” button located in individual share settings which moves all files and ignores mover tuning settings. See point 3 in my previous post. If you can confirm the first 4 points that would be helpful, and the logs in step 5 would be helpful too. Thank you Alternatively: you can move away from the hidden folders approach and simply put the path to the folder you want to skip in the skip files list with that setting enabled. I believe this should work fine for your use case and in the next release will be fully supported.

I'm seeing an issue where I believe this plugin is waking up two disks (disk1 and parity). I can see from earlier comments that it is expected if it is querying snapshots. However what I find strange is that my parity drive is being spun up as well, shouldn't this only happen if a write is occurring? Also in my case I only have a snapshot of my 'appdata' share folder which is located on my cache. For context my setup is as follows (unraid 6.12.2): Array: Parity Disk 1 - ZFS Pool: Cache - ZFS Cache mirror - ZFS I expect that the HDD might spin up if I select the "SHOW DATASETS" in the "main" tab but I usually have these collapsed. I have had the "File Activity" plugin running and it has displayed no files being modified or accessed so I'm a bit stuck. Additionally, I have experienced both disk1 and parity spinning up when entering the "shares" tab as well which was unexpected. Any thoughts/suggestions would be great. I'll try uninstalling the plugin to confirm the issue I installed this plugin right after installing 6.12.2 so I too am wondering if my issues are related to this plugin or 6.12.2 haha EDIT: Upon removing the plugin I no longer get HDD start-up when entering the "Main" tab. This includes both disk1 and parity.

This might be a silly question, but how do I know if paperless-ngx is using redis? I have it installed and on the same custom docker network and I point paperless to "redis://[redis]:6379". Paperless is working but I have no idea if it is actually using redis. I honestly don't really understand how external databases work. I'm also wondering how I backup the redis database because it doesn't have an appdata mapping.

Great! Do let us know if the email ends up coming through again or not. Otherwise I'll ask hugendbb if we can change it permanently. Also keep in mind it will be reset if your server restarts (until it is implemented) Not entirely sure what you mean but the location in sbin is correct and the file SHOULD exist (if that's what you meant).

Yeah this is because the &> is sending both stderr and stdout to /dev/null while "2>" only sends stderr to the void. I think you could achieve this by making the edit in the updateCron.php file. nano /usr/local/emhttp/plugins/ca.mover.tuning/updateCron.php This change will be reverted when your server restarts and the plugin installs. Unfortunately I can't test these commands because I don't have a test rig and this will forgo my current mover settings. Unless it has something to do with the way mover.old is being called in the cron schedule (2> /dev/null), I believe this behaviour is not because of the Mover Tuning Plugin. I don't think that "mover.old" is a Mover Tuning file. Some more questions: When you ran "/usr/local/sbin/mover.old start 2> /dev/null" in CLI did you you get the email? If you uninstall the Mover Tuning Plugin. What mover cron schedule do you have in "cat /etc/cron.d/root"?

Hey so when I initially responded I think I may have been wrong and you might be able to achieve this by just putting the path to the folder in the skip files list (in the file). Just make sure that if you are wanting to use the path "/mnt/cache/data/usenet/intermediate" there are no other paths that contain this same path as part of it. e.g. "/mnt/cache/data/usenet/intermediate1234". I noticed my error in the original response because my implementation of skip folders wasn't behaving as expected and turns out it was because the folders were being skipped anyway due to the original code. Not sure why I thought it didn't work when I first tested it. Regardless will still be working on a more robust solution.

I'm no expert either lol so you're doing good! Interesting results! I actually think your 2nd edit is on to something. I completely overlooked that your question was in response to the "Force move of all files on a schedule" setting and was assuming you were getting the emails from the normal mover schedule. I was testing the wrong things so my apologies. Use the following to change the "2" to an "&". So "2>/dev/null" to "&>/dev/null". nano /etc/cron.d/root Then ctrl+O (the letter) to save and ctrl+X to exit. Let me know if this fixes your issues

A couple things that could be helpful: If you could check if you have mover logging "Enabled", if it is, try disabling and see if you still get the emails (this is not a fix obviously but would be useful info). Alternatively, if it is disabled, try enabling it and see if you get a lot more logs in the email. Do you get the email when you manually run the mover? Before you do this, know that if you do not have "Move Now button follows plug-in filters:" set to Yes, it will ignore mover tuning settings. Set this to Yes first if it'll mess things up for you. Enable "Test Mode:" to Yes and then manually run the mover, do you get the email? Yeah if you uninstall and also do a restart all relevant plugin files should be gone, you can check this by checking if "/boot/config/plugins/ca.mover.tuning" exists. In your first message you state: Is this email happening for any other plugins or cron entries in "/etc/cron.d/root"? I'm inclined to believe this is something triggered outside of the Mover Tuning Plugin because the code is not written to do this but I'll still try to figure it out. EDIT: From what I have found in other posts, people who tend to get these kinds of "cron for user root" emails, tend to be related to errors or issues. It's some kind of unraid feature. The logs you are getting, are regular "echo" logs that appear in syslog. Maybe it's related to the way the script is executed or something else I haven't figured out yet.

Hmm this is not expected behaviour and I have tested on my unraid to be working. A couple things: Make sure that if the particular share with ".folder" is using its own settings (mover settings override) that the setting to ignore hidden files is set to yes in that share. If it is not using its own settings the global settings must be set to yes. Ensure that the type of share is valid (Primary: Cache, Mover: cache-->array), other share types do not use mover settings. Ensure that you're not trying to move files by hitting the "Move ALL" button in the share settings. Ensure that you do not have "Move All from Cache-Yes shares when disk is above a certain percentage:" set to Yes in your share/mover settings. If this successfully executes, it will move all the files off the cache not following settings. Set "Test Mode:" and "Move Now button follows plug-in filters:" to yes, also enable logs. Then run the mover and in "cd /tmp/Mover" use "cat Custom_Mover_Tuning_*latest*.list" this will show the files that will move. None of the files in .folder should be here. IF they are, do the following: "cat Mover_Tuning_*latest*.log". You can post the logs in a spoiler here or send to me privately.

Just as an update for anyone who might stumble across this thread, the changes to be able to change mover settings for individual shares is now officially implemented in the Mover Tuning Plugin. I've marked the first response to check out the Mover Tuning Plugin as the correct solution because well...it's now the correct solution!

Feature has now been officially released! I believe hugenbdd has created something like this but it requires some kind of manual implementation for now, you can see the relevant files on his GitHub.

There is no way to achieve this currently, but I believe there is a small change that can be made to the code to allow for this by simply including the path to the folder in the skip file list. The behaviour would skip all files and subfolders of the path given. I’ll discuss with hugenbdd.

Yep! Fix will be in the next release from hugenbdd I have been trying to figure out this one with no luck so far. I know where the message is originating but just not sure why. What settings do you use on the notifications page? (don't share the smtp stuff just the top section)

Possibly the stupidest thing I have ever done. I finished transferring everything over to my new server today and I needed to delete a directories contents. Instead of using "rm -r ~/*" I missed the ~ so I wiped everything. Was a bad idea to use that to begin with. Worst part is that I had my cold backup drive plugged in (and mounted) as I was transferring data onto my new server. Not the end of the world for my personal documents cus extra backups, but there goes my server config, parity, docker configs and everything else. SO my question is. Is there anything more stupid I could have possibly done? And what is my hopes of being able to recover my docker configs...

Hallo! Ich spreche eigentlich kein Deutsch (benutze einen Übersetzer: Entschuldigung, wenn das nicht ganz korrekt ist). Ich wollte fragen, ob Sie jemals den CyberPower UT850EG bekommen haben? Ich habe mir diese USV vor kurzem gekauft, weil ich gesehen habe, dass das Datenblatt im Leerlauf einen Stromverbrauch von etwa 2 W anzeigt, aber in Wirklichkeit sehe ich einen Stromverbrauch von etwa 5 bis 8 W. Das ist bedauerlich, weil ich ein System mit sehr geringem Stromverbrauch zusammengestellt habe, das etwa 11 W verbraucht, während alle meine Docker laufen (aber die Festplatte im Standby-Modus ist). Es ist bedauerlich, dass dieser Stromverbrauch allein aufgrund der USV auf 16–19 W ansteigt. Wie ich sehe, haben Sie Ihre Tests mit dem VP700ELCD durchgeführt, das einen Leerlaufverbrauch von 2,5–3,2 W zeigte, was meiner Meinung nach viel akzeptabler ist, und ich kann meinen austauschen, wenn er nicht fehlerhaft, sondern einfach nicht so gut ist. Ich nehme an, meine Frage ist, ob Sie jemals den UT850EG gekauft haben und wie hoch ist die Leistungsaufnahme im Leerlauf? Danke

I have found the error now. Expect it to be fixed in the next release

Yeah that is correct but only if you don't want that behaviour. The error is harmless, so don't change it just because of the error if that is the functionality you want

The javascript uses the "toggleAttr" function which always toggles disabled/enabled regardless of the value. Could possibly pass a value and change the function to "disableAttr" which only disables it if the value is "no". This wouldn't fix the error in the initial load in, but would fix it when the user does toggle the setting. I think perhaps an easy fix would be to change each variable in the php script from this: $ageDisabled = ($cfg['age'] == "no") ? "disabled" : ""; to this: $ageDisabled = ($cfg['age'] != "yes") ? "disabled" : ""; This way if the variable does not yet exist it will still be disabled and the HTML will default to "No" because the code is written with this option first?

Yeah so that's just a script that specifies that if setting "age" is set to "no" then make it disabled. It wont change if you edit the settings but if it was set to "yes" somehow that would explain it. It looks like the script is correct so I am not sure why you are getting that behaviour. Unfortunately I don't know much at all about HTML which the rest of that page uses but I can say the code for that page hasn't changed in 2 years. It might be something to do with your unraid version or another glitch. Do you have any other plugins installed and do they have the same behaviour? (for eg. parity check tuning). I might just suggest uninstalling and then re-installing it and seeing if it still happens.

Hmm strange, unfortunately I can't change my unraid version to check but can you use the following in terminal: cat /usr/local/emhttp/plugins/ca.mover.tuning/Mover.tuning.page and show me the following lines (11-21)

Thanks! This confirms the behaviour. Because your nvme_cache pool is above 25% used, it will always move all the shares that are (cache--->array) to the array and ignoring other mover tuning settings. I suspect that you have other (non cache-->array) shares that are taking up more than 25% of the nvme_cache pool, so this behaviour will always happen. This results in all files in those shares being listed for a move, but then they are again listed later for a move based on the mover settings (because the mover only runs once at the end). As a result, it gets moved and then later when it tries to move it again, it no longer is in the original directory and hence lstat error. Hugenbd has implemented a check to see if the file/directory exists before attempting the move. The error is harmless but will be fixed in the next release

Oh yep sorry! edited lol...wrote that one at 6am after not being able to sleep. 😬

My implementation is going well, some good news and some bad news! Good News: Per-share mover functionality is fully up and running. GUI created and functional. Initial testing shows expected results. Bad News: The per-share mover settings will run at the same time as the normal mover. There will be no separate mover schedules. It will only work for cache-->array moves (shareUseCache="yes"). This is because the current Mover Tuning Plugin only uses the settings for this move (to the best of my knowledge). But I believe this is probably covers 95% of peoples use cases anyway. It's gonna require more testing and validation before release. Supported Settings: AGE: Move based on age. Use CTIME (as opposed to MTIME) SIZE: Move based on min size. Sparseness: Move files based on min sparseness. FILES LIST: Ignore files in a list. <-------- I might remove this one, because it doesn't really make a difference and is more limited FILE TYPES: Ignore specified file types. HIDDEN: Ignore hidden files and directories. Move All From Cache Threshold: Toggle only, threshold set in main settings.