To try and keep it succinct, I'm trying to using Lidarr combined with a script that integrates Deemix (https://github.com/RandomNinjaAtk/arr-scripts), and the default configuration of the script makes it to where it downloads in the appdata folder (I tried to change this, but the behavior got weird so I was planning to just keep it this way for now). Lidarr then atomic moves the music files into my designated music directory (which isn't a child folder of appdata).
Unraid then seems to get confused and won't move these files because they "exist" already. Well... they don't exist where I want them. My appdata is set to use my NVMe cache, while my music directory is set to be on my array, but Unraid won't move them. I've checked the disks and files individually and they are indeed not on the array but instead on the cache disk and permanently filling up my cache. Any idea how to fix this?
This is the Github issue I posted for the script that has more details and screenshots attached. It's probably not a script issue but I just went there first to see what he had to say.
As far as I can tell, all my Unraid settings are correct so I'm pretty confused. Maybe I have something configured wrong though. Container PUID/PGID is 99/100. Maybe it needs to be root 0/0? Doesn't seem it like though since it theoretically is the literal root operating system that's struggling to move these files regardless who owns what. But idk considering the non root-owned files like the extra .lrc and .jpg are moving successfully maybe it has something to do with it. I just don't see why it would.
SOLUTION: files that are created on a share, and then moved to a share with different disk/mover settings, will break mover. Unraid/Linux doesn't support this, you need to handle them on the same share. Unraid's error message is incorrect and misleading.