-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot Move to NAS with "Move" #9
Comments
That's strange, you should be able to do that, do any other file modes work (copy, symlink etc)? At fist glance it looks like a permission issue. FileBot will be launched with the same permissions that the deluge daemon has, so make sure that deluge has permission to write to the |
The deluge user has appropriate permissions, as I'm able to manually rename and move files within deluge. The FileBotTool can also rename files in place or anywhere on the same drive. It cannot move files to a different drive, even if they don't need to be renamed (I just manually moved a file back and tried to move it again using the tool). A buddy (who works for red hat) and I spent several hours the other day attempting to debug this as a permissions issue, to no avail. The method being called is moveRename() in https://github.com/filebot/filebot/blob/master/source/net/filebot/util/FileUtilities.java. which calls Files.Move() from which seems to indicate that this method will throw an IOException when the destination is on a different FileStore. If my understanding is correct, the best place to fix this would be upstream in the FileBot project itself, but I believe it would be possible to work around this by doing a copy and then delete. |
I forgot to mention also, that Copy mode does work, but defeats the purpose of the tool for me, which is to have organized files with no duplicates. and Links just seem messy. If nothing else, the easiest workaround is renaming the files in place with the tool, and manually using the "Move Storage" option in Deluge. |
Well that's a pain. I'll flag @rednoah to make sure he sees this. In the meantime, I'll see if I can find a reliable way to figure out if the destination is on a different filestore from within python and have deluge handle the output path moving. |
Thanks for looking into it. Like I said, I've figured out the closest thing to a workaround for now, and it only affects files that weren't caught by Flexget in the first place, so its not a huge deal. |
I have this problem too! But when it DOES work, it Filebot always leaves off the the first letter of the moved file. And of course I can't change it or the file will stop seeding and cause an error message in Deluge. :( |
SMB/AFP/NFS filesystem abstraction is handled by the operating system, so FileBot doesn't even know if it's dealing with local or remote files. FileBot itself and the Java NIO.2 APIs just use the "local" filesystem, so all the SMB/AFP/NFS stuff is handled by the OS outside of the FileBot/Java process. Googling all sorts of CIFS might get you lucky. If I were to thorougly debug the problem I'd look into how You might also want to look into any kind of app sandboxing like AppArmour and things like that. Maybe the process is prohibited from deleting the original file which makes the move fail? |
@Latinkidmj no logs => no support |
I'm going to close this since I can't really re-create it and it seems to be an OS issue. |
I was getting this in my filebot-node docker instance, and I figured out why, and wanted to document it for others who stumble across this thread. For me, the error was that input and output were on different filesystems (not really, but with the way docker was mounting bind volumes, it appeared that way to the app. From a docker point of view, I was mounting source and destination as separate volumes:
even though todo is just a peer level directory to Movies. Before: resulted in: After: That change had it appear to Filebot & Java that it was working on the same volume / filesystem and the program ran without a problem and moved my files where I expected. Hope this helps someone! |
I am unable to move files to my NAS (mounted as CIFS) using the tool, for what appears to be a java error. After some searching, it appears the FileUtilities.moveRename() method cannot move files across drives (or to mounted shares). Would you be able to make the tool detect that the destination is on a different drive, and have Move mode copy and then delete the source files?
Error output below:
The text was updated successfully, but these errors were encountered: