[
https://issues.apache.org/jira/browse/NIFI-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018786#comment-17018786
]
Joe Witt commented on NIFI-7041:
--------------------------------
PR that is up in https://github.com/apache/nifi/pull/4000 has been manually
tested.
Before the PR if permissions are not supplied then the remote file is written
but has permissions of 000.
After the PR the permissions are whatever the default umask is for the user if
the permissions property is not set OR if it is set to the flowfile attribute
of file.permissions but that attribute has no value. Only when the permissions
value is explicitly set to 000 would the resulting permissions be 000. Further
it was confirmed that other excplit settings for permissions works as expected.
Not clear how this would be unit tested safely given the portability of file
permissions on different systems. But the manual test is quite easy to do and
the comment explains why we're setting the values as we are.
This change restores the expected behavior.
> PutSFTP 1.10 Default permissions blank
> --------------------------------------
>
> Key: NIFI-7041
> URL: https://issues.apache.org/jira/browse/NIFI-7041
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.10.0
> Reporter: James Ignatius
> Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Recently updated our NiFi environments from 1.8 to 1.10. Issue occurs with
> PutSFTP 1.10 processors. If the Permissions property is left blank, the file
> is put with no permissions. In previous releases, and according to the nifi
> docs, if the permissions are left blank it should default to the original
> permissions.
> Sample file put using PutSFTP 1.10:
> ---------- 1 9542 9544 1788 Jan 13 20:59
> Test-2018-05-13-2018-05-19.zip
> The workaround is obviously to be sure and set the octal number for
> permissions, though if you forget, you can end up with thousands of
> unpermissioned files which require root to delete or re-permission.
> Sometimes the file errors, and sometimes it does not. I have observed this
> error in the app log on some of the files:
> Failure java.io.IOException: Failed to rename dot-file to
> /data/incoming/OSDM_CORE_aplgenff010_20200115140000.zip due to 4: Failure
> at
> org.apache.nifi.processors.standard.util.SFTPTransfer.put(SFTPTransfer.java:766)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
