When I run the beeline command on Hadoop Edge nodes, the commandline shows below warning messages saying permission denied while reading the log files by one agent under "/opt/dynatrace/oneagent/log/java" (on Linux OS). However, when I run the same command as a root its working fine and creating the log files in the same location.
Can you please advise, if there ant config setting can be changes to fix the issue. We noticed this issue with beeline as of now.
Cannot open log file '/opt/dynatrace/oneagent/log/java/ruxitagent_org.apache.hadoop.util.VersionInfo_bootstrap_57136.0.log': Permission denied
Solved! Go to Solution.
There errors are most likely caused by bad permissions on Oneagent directories.
- What is the ownership and permissions of /opt/dynatrace/oneagent/log/java ? (post a "ls -al" output)
- Is your Linux agent running in non root mode or in root mode?
Yes, the directory owned by root. We see this issue only for maprcli commands. For other Java related apps, it is working fine.
drwxrwxr-t 2 root dtuser 233XX Nov 21 07:00 java
Your current permission require the user starting the Java process to be either root or member of the dtuser group to be able to write logs into this directory. So either you add the write permission to others or you need to add the user into the dtuser group.
Did you install the Dynatrace Agent from the root user?
If not, the easiest way will be to reinstall the agent using the root user.
The Dynatrace user will then be given appropriate permissions to instrumentation of application processes.
Apologies for the late reply.
If I add the WW permissions, the issue is not reoccurring. However, this is not a best practice from Security standards.
Though we installed the agent with a root user, still it is expecting WW permissions. Does Dyntrace has any solution?
Actually this is ok, the log file directory must be writable for any user. Normally this should have following permissions and ownership:
drwxrwxrwt 1 root dtuser 182 Dec 13 08:57 log
Notice the t flag, this will prevent removing files not owned by the process.
The directory must be writable for everybody, since oneagents injected into applications are running in context of the application itself and typically run as different user than the OS part of oneagent.
I think you have some hardening / security script running on your system to find directories writable for everybody and changing permissions. Or someone did this manually.