July 7, 201510 yr Sorry, my mistake (just recently moved from v5). It appears there is no longer a "disable" option. You could simply rename mover to mover.bak or something. Or use "hidden" folders on your cache drive.
July 7, 201510 yr Author I can give the rename a try...maybe the guys @ LimeTech can fix that feature in the next update....hint hint hint.
July 7, 201510 yr You can disable the use of cache enabled shares from the global share settings page.
July 8, 201510 yr Community Expert Just set your share to cache only and mover will not touch any files in that share This is the usual solution. If this is not enough, why exactly do you want to disable mover?
July 8, 201510 yr Just set your share to cache only and mover will not touch any files in that share This is the usual solution. If this is not enough, why exactly do you want to disable mover? And as mentioned, you can disable the moving from the cache drive to shares by changing the setting Use cache disk to NO under global share settings.
August 25, 201510 yr Where can I request the feature to disable the mover? In the previous version, I would set it to run on a fictitious date. Why do I need to disable the mover and still need cache shares? So that I can control when to move cached items after a manual QC process. So for example, if I have a new spreadsheet I am automating, I want it to appear in the array to normal users. Only when the spreadsheet has passed QC will I commit it to the array. Sometime the file (a spreadsheet or database file) contains a lot of test data that don't need to be on the array, so when I commit the file, I remove all the test data. Having on the cache drive is a great staging area because other users or devices can access beta files just like production files (all from the same share).
August 26, 201510 yr If you want to disable the mover from the GUI, you need to make that a feature request.
August 26, 201510 yr Where can I request the feature to disable the mover? In the previous version, I would set it to run on a fictitious date. Why do I need to disable the mover and still need cache shares? So that I can control when to move cached items after a manual QC process. So for example, if I have a new spreadsheet I am automating, I want it to appear in the array to normal users. Only when the spreadsheet has passed QC will I commit it to the array. Sometime the file (a spreadsheet or database file) contains a lot of test data that don't need to be on the array, so when I commit the file, I remove all the test data. Having on the cache drive is a great staging area because other users or devices can access beta files just like production files (all from the same share). Why not just create a "Staging" share and set it to cache only ( mover will not touch files in a cache only share ) then after your QC process move it to a share that mover will put onto the array when it runs? Seems better than having an option to disable mover that only a handfull of users will need/want to use.
August 26, 201510 yr Where can I request the feature to disable the mover? In the previous version, I would set it to run on a fictitious date. Why do I need to disable the mover and still need cache shares? So that I can control when to move cached items after a manual QC process. So for example, if I have a new spreadsheet I am automating, I want it to appear in the array to normal users. Only when the spreadsheet has passed QC will I commit it to the array. Sometime the file (a spreadsheet or database file) contains a lot of test data that don't need to be on the array, so when I commit the file, I remove all the test data. Having on the cache drive is a great staging area because other users or devices can access beta files just like production files (all from the same share). Why not just create a "Staging" share and set it to cache only ( mover will not touch files in a cache only share ) then after your QC process move it to a share that mover will put onto the array when it runs? Seems better than having an option to disable mover that only a handfull of users will need/want to use. Having a separate share means users and software must be reconfigured when something moves from staging to array. Disabling mover works better because everything shows up in the same share regardless if it is in the array or on cache. Don't forget, the option to disable mover is there prior to V6. So technically, instead of a feature request, I should be submitting a bug report.
August 26, 201510 yr I personally don't think this is a bug at all but more of a fix, disabling the mover negates one of the core functions of unRAID with a cache drive. I agree that you have a special case and do not want to setup cache only shares. Also i just though of this, (I think) you could setup a cache only share & a user share with the SAME name you could move stuff from the cache only share to the user share manually and it should accomplish what your wanting Edit: Just tested this and it does work as described
August 27, 201510 yr I think you are mixing terms of shares and directories. To me a share is a SMB logical representation of a network storage. It is only defined in the SMB configuration. A directory is a physical folder on a disk. unRAID distinguishes between cache only and user (?) shares are confusing, but ultimately you can only have one SMB share on the network. In other words, you cannot configure two shares with the same name via Shares->Add Share. I am not asking to disable the mover, I am asking to disable the scheduler of the mover. The mover can still be initialized with the Move Now button.
August 27, 201510 yr Community Expert See here I'm sure this will not survive a reboot unless you reapply it in go
October 9, 201510 yr Stopping the Mover can be important when the mover is associated with a serious bad consequence, such as in this thread: http://lime-technology.com/forum/index.php?topic=39510 I am suffering from that issue, that brings my machine down every week or so, and by reports of others, it is related to Mover overlapping with a process in some Docker containers. I'd like to disable Mover and have it run manually until this gets resolved. The UI seems to allow us to specify exactly when the mover should run automatically, but not *if* it should run automatically. "Why should we need to?" Because sometimes we need to. Sorry. Grumpy over my fifth hard reboot in a month. Dennis
October 9, 201510 yr Stopping the Mover can be important when the mover is associated with a serious bad consequence, such as in this thread: http://lime-technology.com/forum/index.php?topic=39510 I am suffering from that issue, that brings my machine down every week or so, and by reports of others, it is related to Mover overlapping with a process in some Docker containers. I'd like to disable Mover and have it run manually until this gets resolved. The UI seems to allow us to specify exactly when the mover should run automatically, but not *if* it should run automatically. "Why should we need to?" Because sometimes we need to. Sorry. Grumpy over my fifth hard reboot in a month. Dennis It is possible to manually stop the mover. Do the following from the command line: rm /boot/config/plugins/dynamix/mover.cron update_cron
October 11, 201510 yr It is possible to manually stop the mover. Do the following from the command line: rm /boot/config/plugins/dynamix/mover.cron update_cron Thanks very much, I renamed the mover.cron for the time being. D
October 11, 201510 yr Community Expert It is possible to manually stop the mover. Do the following from the command line: rm /boot/config/plugins/dynamix/mover.cron update_cron Thanks very much, I renamed the mover.cron for the time being. D Unless you also update_cron renaming it will have no effect since it has already been put in cron. And it will get recreated on boot.
October 13, 201510 yr It is possible to manually stop the mover. Do the following from the command line: rm /boot/config/plugins/dynamix/mover.cron update_cron Thanks very much, I renamed the mover.cron for the time being. D Unless you also update_cron renaming it will have no effect since it has already been put in cron. And it will get recreated on boot. Thanks, yes I did update, and will just live with the recreate on boot.
Archived
This topic is now archived and is closed to further replies.