Re: [X2go-dev] bash settings missing

2010-02-03 Thread John A. Sullivan III
On Wed, 2010-02-03 at 08:08 -0500, John A. Sullivan III wrote: > On Wed, 2010-02-03 at 13:55 +0100, Oleksandr Shneyder wrote: > > John A. Sullivan III schrieb: > > > Hello, all. Amidst our very successful testing of X2Go, we came across > > > a permissions issue. Our environment sets a default um

Re: [X2go-dev] bash settings missing

2010-02-03 Thread Paul van der Vlis
John A. Sullivan III schreef: > Thanks, Paul. That's a very creative idea but it means either editing > thousands (hopefully) of clients spread all over the world or replacing > the startkde file with a script and remembering that after every upgrade > for every virtual machine (we map one virtua

Re: [X2go-dev] bash settings missing

2010-02-03 Thread John A. Sullivan III
On Wed, 2010-02-03 at 13:55 +0100, Oleksandr Shneyder wrote: > John A. Sullivan III schrieb: > > Hello, all. Amidst our very successful testing of X2Go, we came across > > a permissions issue. Our environment sets a default umask of 007 rather > > than the standard 022. This was honored in our N

Re: [X2go-dev] bash settings missing

2010-02-03 Thread Oleksandr Shneyder
John A. Sullivan III schrieb: > Hello, all. Amidst our very successful testing of X2Go, we came across > a permissions issue. Our environment sets a default umask of 007 rather > than the standard 022. This was honored in our NoMachine environment. > However, we recently started having access co

Re: [X2go-dev] bash settings missing

2010-02-03 Thread John A. Sullivan III
On Wed, 2010-02-03 at 13:05 +0100, Paul van der Vlis wrote: > John A. Sullivan III schreef: > > Hello, all. Amidst our very successful testing of X2Go, we came across > > a permissions issue. Our environment sets a default umask of 007 rather > > than the standard 022. This was honored in our No

Re: [X2go-dev] bash settings missing

2010-02-03 Thread Paul van der Vlis
John A. Sullivan III schreef: > Hello, all. Amidst our very successful testing of X2Go, we came across > a permissions issue. Our environment sets a default umask of 007 rather > than the standard 022. This was honored in our NoMachine environment. > However, we recently started having access co