I'm having the same issue documented here http://www.splunk.com/support/forum:SplunkGeneral/3130
"An example is the Unix app. When this app is pushed to a Splunk instance using the deployment server the scripts under unix/bin lose their execute permissions."
The permissions on the deployment server are -r-xr-xr-x but on the client they become -rw------
The problem with file permissions and ownership is based on the interpreting file system. This means that if you transfer files from one file system to another that the receiving file system will usually not be able to read the "properties" of the file such ownership and permissions.
To break it down further, if a file has specific permissions and ownership properties on a machine with FAT or NTFS files system and it is transferred to a machine with ext/reiser/hfs/(other *nix variants), then the file properties are typically lost. This same rule applies for a file transfer in the opposite direction (e.g. *nix to Windows) as well.
This file system interpretation issue can sometimes be worked around using tar to keep permissions of files within a tar package intact. However, this would only allow for the files to keep the permissions intact if both the endpoints use a file system that can interpret the same file permission properties. This means that a tar package containing files with permissions from a *nix system will be maintained as long as the files are un-packaged on a *nix system. It doesn't matter if the tar file had been transferred from another file system. Here is an excerpt from the tar man page:
Theoretically, if you were to create a deployment package on Windows using tar to preserve the file permissions, then you could then possibly deploy that package from a *NIX machine as long as the files had not been extracted from the package and re-packaged. The same could be said for a *NIX package created on a *NIX machine but stored on a Windows deployment server.
Then it would simply be a matter of deploying the correct package based on the target OS.
answered 21 Jan '11, 17:15
did you check the umask on the deployment clients? this can result in very strange file permission when untaring files - read more here http://www.sun.com/bigadmin/content/submitted/umask_permissions.jsp
answered 03 Mar '11, 14:57
I heard this was some type of feature, so that a malicious person cod not make a new app with a malicious script inside it that could be deployed onto a deployment client and run to do malicious tasks on your server.
answered 19 Aug '10, 03:36
We stepped through this exercise with Support's help and it seems to be an issue when deploying form Windows.
We were only interested in deploying the unix app to machines that would act as forwarders, thus the way we solved it was to deploy a "unix-enable" app, which just switched on the inputs on the forwarders.
This wasn't a problem as the unix app was deployed by default as part of the Splunk install and the permissions for the scripts were set correctly.
answered 06 Jan '11, 12:15
I just run in to the same issue.
Deployment host is on Linux, client is on Solaris. While it seems to work on systems using ZFS, it does not seem to work on UFS.
Untaring the bundle (with Solaris' tar) from /opt/splunk/var/run/ime/solaris-1305840239.bundle does in fact preserve the permissions on UFS.
Maybe Splunk uses another tar for this...
answered 20 May '11, 13:20