CS01-HS

Huh, clear differences between your file view and mine. Not sure why - best to ask in another thread.

A file browser's built it. Go to shares in the top menu and navigate to the file then use the file menu to delete or change permissions.

The plugin's working great but I don't understand the rationale for a warning for "no internal mappings." In theory if I set the container to skip the only difference is the warning! But in practice that's not the only difference: I have a container with no internal mapping as part of a group (because its start order is important.) If I set it to skip it's not restarted so it loses communication with the container it depends on, which is. If I don't, I get the warning. Is there an approved way to handle that? I come back to the warning though - plenty of containers with no "appdata" so why warn about a normal condition? Maybe something I'm missing.

The ordering bug (?) only affects containers with no group assignments. Regardless, you should group these. Where container B depends on container A: without groups: A is stopped for backup which may cause errors with B, before B is stopped for backup with groups: B is stopped, then A is stopped, then both are backed up, then A's started, then B's started

That's how I had it initially: But I haven't used this script in years (I eliminated the USB drive) so much may have changed. If it works, it works!

Re: Warnings for non-existent volumes: There's the xml template, or is that backed up even if the container's skipped? That and consider the case of a container that doesn't use volumes: We set it to skip A subsequent version does use volumes We won't know not to skip it until it's too late Backup Order In the new version with Backup type set to stop, backup, start for each container For grouped containers: They're stopped in reverse of Start order (good) They're backed up in reverse of Start order (fine either way) They're started in Start order (good) For un-grouped containers They're stopped, backed up, started in reverse of Start order (bug?)

Oh, I didn't realize. I was going off the debug output in test mode. I tried a real run (now with full paths) and it works. Thanks!

File-exclusion works as expected but folder-exclusion only excludes the folder itself, nothing under it. e.g. given the folder structure: MyShare/KeepOnCache/ File1.txt File2.txt And this entry in the exclude file: /mnt/cache/MyShare/KeepOnCache the find command (with sed evaluated) look like this: > find "/mnt/cache/MyShare" -depth | grep -vFx "/mnt/cache/MyShare/KeepOnCache" /mnt/cache/MyShare/KeepOnCache/File1.txt /mnt/cache/MyShare/KeepOnCache/File2.txt So File1.txt and File2.txt are not excluded from mover. Is that intended and if so what's the point of folder-exclusion?

Okay let's set that aside. Exact match (-x) means folder exclusion can't work because while the folder will match none of the files within it will.

I noticed folder exclusion using the File list path option stopped working. Enabling test mode I see this in the find command (where my exclude file is exclude.txt) grep -vFx -f <(sed 's/\/*$//' '/boot/extras/mover_tuner/exclude.txt') I don't see how this can work with the -x option: -x, --line-regexp Select only those matches that exactly match the whole line. For a regular expression pattern, this is like parenthesizing the pattern and then surrounding it with ^ and $. Even files in exclude.txt won't satisfy the exact match unless they're prefaced with the cache path, e.g. /mnt/cache/sharename/file.txt vs simply sharename/file.txt, which used to work. Am I missing something?

Yes. By default I think only subtitles save to the library directories but you can disable that. And consider this to synchronize watch state between the two: (It's not in the app store so you have to install manually) https://github.com/ArabCoders/watchstate But backup your watch states beforehand because a misconfiguration could reset it.

In my case the half a dozen times it happened were all triggered by SMB operations. Never happened in any other case and since the new implementation where cache-only shares bypass shfs (and the majority of my SMB use is cache-only shares) it hasn't happened since.

I didn't see it mentioned (maybe my search was insufficient) but it'd be handy if a share's recycle bin were emptied automatically when "free" dropped below a certain value or %, in case of emergencies. I'm in the process of standardizing my media library with unmanic so lots of churn, which made me think of it. I could do it with a simple user-script but that only solves it for me, and it's not as clean. Something to consider if you end up with too much free time!

If I'm reading this right: one of the two connectors may offer 4 ports from the JMB585.

I've fixed it (until the next reboot) with a symbolic link: ln -s /usr/local/bin/move /usr/local/sbin/move Seems to be running properly but hasn't finished yet.