Manage profiles for nonroot users

The nonroot user can receive permissions for files and directories so that the nonroot user can create a profile.

This task assumes a basic familiarity with the manageprofiles command, the Profile Management Tool, and system commands.

This task uses the following terms:

Remember: An ease-of-use limitation exists for nonroot users who create profiles. Mechanisms within the Profile Management Tool that suggest unique names and port values are disabled for nonroot users. The nonroot user must change the default field values in the Profile Management Tool for the profile name, node name, cell name, and port assignments. Consider assigning nonroot users a range of values for each of the fields. We can assign responsibility to the nonroot users for adhering to their assigned value ranges and for maintaining the integrity of their own definitions.

Best practice: IBM recommends starting processes that run on the same profile with user IDs that have mutually compatible file permissions, meaning that each process can read or update files that the other processes create. This ensures that the processes can access the same files without encountering a permission-denied error. For example, if you run the deployment manager as user wasuser and then also run the tool to generate plug-ins on that same profile, you should run the tool as user wasuser.bprac

Tip: In WebSphere Application Server v8.5, files created by an administrator outside of the Program Files directory are usable by non-administrators. Therefore, profiles created outside of the Program Files directory can be used by non-administrators to start the server and so on.

Nonroot users might typically need these tasks completed so that they can start their own application servers in development environments. For instance, an application developer might test an application on a application server in a profile assigned to that application developer.


Depending on the tasks that the installer followed, the installer has completed the following actions:

Connections to the Derby database might not work, and you might see errors like the following in the logs:

This can happen when files under app_server_root are read-only. We can configure Derby to write its log to another location by setting the following property in the app_server_root/derby/derby.properties file

What to do next

Depending on the tasks that the installer completes, a nonroot user can create a profile, start WebSphere Application Server, or do both.


Related tasks

  • Assigning profile ownership to a non-root user
  • Granting write permission for profile-related tasks
  • Change ownership for profile maintenance