Currently, the GetSmbFile processor is pretty much unable to handle read-only files when the "keep source file" property is set to "false". This is due to the way the processor tries to remove the source file and the way the underlying Hierynomus library handles read-only files. Essentially, regardless of the permissions that the account NiFi is using to access the SMB share has on the folder or file in question, Hierynomus will never allow a file to be removed while the read-only flag is set.
Because of this, when NiFi calls 'share.rm(file)' Hierynomus throws an exception which then surfaces in the NiFi logs and UI. The source file is not removed, but a flowfile is generated and routed to the "Success" relationship.This results in the same source file being ingested dozens of times per second, with each one generating both an error message and a successful flow file. While this is documented behaviour within the Hierynomus documentation for the read-only attribute (https://www.javadoc.io/doc/com.hierynomus/smbj/0.0.5/com/hierynomus/msfscc/FileAttributes.html#FILE_ATTRIBUTE_READONLY), it is pretty unclear from the NiFi documentation that the GetSmbFile processor will react this way to a read-only file. I'd like to suggest adding explicit support for handling read-only files as a property of the processor, IE a "Force Remove Read-Only" property. Assuming that NiFi has the correct permissions, it is possible to handle read-only files by opening the file, updating the file attributes to remove the "read-only" flag, and then closing the file. As long as this is done before calling share.rm(file), the file should be successfully deleted. I'm currently running a modified version of the GetSmbFile processor that does exactly that, but this feels like it should probably be built-in functionality available to the processor out of the box. I'm not exactly sure what the process is for requesting features, but I thought I'd throw the idea out here and see. -Evan
