We’re working with a very limited number of windows boxes on our renderfarm, connected to our servers via SMB.

In the event that the windows box runs a deadline job, it’s restricted to saving files over smb to our network as a very specific user:group (deadline:service).

This causes a bit of problem, but I haven’t figured out an elegant solution.

Can anyone chime in on how they handle Window-based render nodes and file permissions? Any anecdotes would be appreciated!

What’s are the specific problems with that happening? I’m assuming folks aren’t able to view output as they’re not in the “service” group.

Have you looked into ACLs and user groups? What is your current network permissions layout here?

I’m hoping to see how others are working with a Windows box as a render node.

The challenge is trying to replicate what happens on Linux: A user can launch a job/plugin as themselves and inherit the permissions of that user.

At the moment, we have the windows box connected to our linux services via smb, and is mapped as the user “deadline:services”. When we write anything with this method of access, it’ll always be as “deadline:services”. They are able to view the output, but they won’t be able to modify/delete the output. It’s stuck unless an admin goes in there and mucks around.

The next option I imagine would be to change the deadline group to the same group as the artist, but that would open up security issues when someone happens to visit the windows box and realizes they now have access to everything artists do as well.

I’m hoping to find out what others are doing, and what works for them. Maybe I can run a separate AfterJob script that will change permissions?

I’ll open the floor for others then.

One thing to note though is that at the moment we have a bug in the Windows’ user impersonation where the environment does not shift quite right so applications may try to use a different user’s temporary folder and such.