Render user permissions and NDA job workflows

At our studio, we have a render service user that runs Worker when a user logs out of their machine. Otherwise, the user can launch Worker themselves manually or it’ll run through idle detection under that user’s account. The issue we run into is on NDA jobs where certain jobs have restricted access and only allow users on that job. So when a user submits a job from that NDA job, it will render fine with our render service user but error on the normal users saying it cannot load the scene.

We do not have Render Job as User enabled. I tested enabling it and changing the credentials of the submitting user to that of the render service user, but that just led to other permissions issues with AppData and plugin sandboxing.

Anyway, I was wondering what others have done to workaround this? What is the suggested workflow?

Some thoughts I had were to have dynamic groups. I already made a script that adds machines to the proper groups upon Worker startup. So they automatically get added to gpu or cpu and whatnot. I was thinking of adding a feature where when the Worker starts up, if it is running under the render service user, then it’ll add the groups nda_gpu and nda_cpu. Then when it starts up under a regular user, it’ll just remove those groups. Am I overthinking the solution?

The groups idea isn’t a bad one - but what happens if there’s only NDA work to do? If it’s okay that the farm sits idle at those times you’d be okay. You’d be able to do that in an event plugin tied into OnSlavedStartedCallback.

If it weren’t for the idle detection feature not working while running as a service I’d suggest just never running the Worker as a user.

The render as user feature should be the solution for this, but it’s not behaving properly on Windows at the moment. I’m don’t think it would be a good idea but you could change the job user on every job to the render user, and leave render as user enabled. That’ll have the Worker run the render application as the render user no matter what system user is running the Worker. You’d still have issues with permissions, but the render user would be the only needed addition.

The more I think about the last one the less I like it.

Let us know what you think!

Thanks for the reply. That’s helpful. I just wanted to make sure I wasn’t going down the wrong path and overlooking an easy solution.

I think I’ll proceed with the dynamic NDA groups as I already have the auto configure startup script. Not much more to implement it to check for which user it’s running under and either add to the NDA group or remove the NDA group.

Thanks.

2 Likes