If those roles create packages that other roles are supposed to have edit rights on, the roles not mapped to root will not be able to make changes to the underlying filesystem.
If it's unix, setup the 2-agents thing for the fileserver since the customer wants to manage the file server.
I know this issue.
Actually, all roles are mapped to root.
The only thing is that they are only enabled for CM, as the customer doesn't want them to access appserver via NSH.
What other commands are needed for managing the file server via CM?
Depends what you mean by manage.. you are probably going to have to take out ‘commands=CM’ for the role you want to manage the file server.
By managing file server I mean being able to create and modify objects in the depot
For just creating/editing/etc depot objects I thought commands=CM was enough.
You need to be careful here though. CIS compliance jobs and the standard BDSSA inventory jobs run various extended objects from the file server by default. We moved them to the App Server(s) and edited the configuration objects to get around this limitation.
Also, if you use the advanced file server/repeaters, then these execute nexec //opt/bmc/.../runchannel.exe against the file server and this fails if you only have commands=CM
we had to use the following to get this to work:
I was looking for it on Norris, but I thought you still needed nexec, cp, and mv