Author Topic: proxy user umask  (Read 4389 times)

pinkwerks

  • Sr. Member
  • ****
  • Posts: 26
    • Method Studios
proxy user umask
« on: October 27, 2008, 05:39:02 PM »
Hi.  We're using a proxy user to run our renders.  It uses bash.  It's ~/.bash_profile & ~/.bashrc source a common file to configure the environment.  One of those settings is the umask set to 0002.  Currently our rendered images are being created mode 644, which is puzzling.  It seems that when I do a simple test `qbsub umask` it reports 0022.  Strange because if I `su - proxy-user -c umask` I get 0002.  Which leads to the question, why isn't the proxy-user sourcing the bash startup files?  Or rephrased, how can I control the umask of the proxy user if it's not reading .bash* files?

thanks.

shinya

  • Administrator
  • *****
  • Posts: 232
Re: proxy user umask
« Reply #1 on: October 28, 2008, 03:56:44 AM »
Hi pinkwerks,

Try setting it in the ~/.profile for the qubeproxy user.
I've successfully verified that it works.

-shinya.

pinkwerks

  • Sr. Member
  • ****
  • Posts: 26
    • Method Studios
Re: proxy user umask
« Reply #2 on: October 28, 2008, 09:58:17 PM »
Ah hah!  That worked, thanks.  Why bash isn't using .bash_profile or .bashrc is beyond me, but I'll take the work around.

thanks again.
-pink

pinkwerks

  • Sr. Member
  • ****
  • Posts: 26
    • Method Studios
Re: proxy user umask
« Reply #3 on: November 10, 2008, 07:29:27 AM »
Nevermind it's still broken.  So to recap, I have umask 0002 set in ~/.profile (which makes no sense since my qube proxy user is running bash), also both my ~/.bashrc & ~/.bash_profile set the umask to 0002. 

Soooo, any clue on how to fix this?

FYI, the difference from last time and this, is that I'm submitting jobs from within Maya now, instead of GUI.  If I submit from the GUI I get the correct permissions.

pinkwerks

  • Sr. Member
  • ****
  • Posts: 26
    • Method Studios
Re: proxy user umask
« Reply #4 on: November 19, 2008, 11:20:20 PM »
So, in case anyone else is having problems with this - pipelinefx wrote me (in a seperate email exchange) this is going to be fixed for the worker in the next dot release.