Re: Permissions problem mounting file from ConfigMap

2017-12-13 Thread Graham Dumpleton 
I don't know. But should be within a minute or so.

Do note that this refresh ability does depend on it being enabled in the 
cluster master configuration. It should be, although have seen where cluster 
was upgraded from 3.5 to 3.6, the setting somehow got lost and had to be fixed 
after the fact when issue was found that refresh wasn't occuring.

Graham

> On 13 Dec 2017, at 9:33 pm, Joel Pearson  
> wrote:
> 
> Oh, I didn't realise configmaps got updated without a Pod restart.  How long 
> does it take to update?  I see in 
> (https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#mounted-configmaps-are-updated-automatically
>  
> )
>  it says the kubelet sync period + ttl.  What are the OpenShift defaults for 
> that?
> 
> On Wed, Dec 13, 2017 at 8:41 PM Graham Dumpleton  > wrote:
> If you copy it rather than symlink, you will loose the ability that an update 
> to the configmap will be reflected automatically inside of the container 
> after a short period. If the file was something that was rescanned by the 
> application, this allows changes to be pushed into a container without 
> needing to do a restart. If you only read the file once on start up, then 
> copying would be fine.
> 
> Graham
> 
> 
> 
>> On 13 Dec 2017, at 8:26 pm, Tim Dudgeon > > wrote:
>> 
>> Graham,
>> 
>> Thanks for your help on this.
>> I had managed to work around the problem in a way similar to how you 
>> described (but copying not symlinking). Not nice, but it works! 
>> 
>> On 12/12/17 21:10, Graham Dumpleton wrote:
>>> A belated update on this.
>>> 
>>> The problem with using subPath is due to a SELinux issue in the kernel.
>>> 
>>> There is an issue about it at:
>>> 
>>> https://github.com/openshift/origin/issues/16951 
>>> 
>>> 
>>> Whether you see it will depend on how SELinux is setup I guess.
>>> 
>>> The only work around would be to mount it as a directory '..data' in the 
>>> target directory, and then you create a symlink from startup run script in 
>>> your source code to symlink the file in the '..data' directory into the 
>>> parent. Know of no other solution at this point.
>>> 
>>> Graham
>>> 
 On 9 Dec 2017, at 8:36 pm, Tim Dudgeon > wrote:
 
 If you mount onto a new directory you get the same problem.
 It only seems to happen when specifying a subPath as follows:
 
 - mountPath: 
 /usr/local/tomcat/webapps/portal/META-INF/context.xml
   name: squonk-sso-config
   subPath: context.xml
   readOnly: true
 
 If the whole configMap is mounted to a directory the contents are readable.
 
 And as mentioned already, if you do this in Minishift it works fine.
 
 
 On 09/12/17 02:16, Graham Dumpleton wrote:
> The permissions is correct. It is shown as decimal, not the octal you are 
> setting it with.
> 
 '%o' % 420
> '644'
> 
> What happens when you mount the configmap onto a directory separate from 
> anything else?
> 
> Graham
> 
>> On 9 Dec 2017, at 4:02 am, Tim Dudgeon > > wrote:
>> 
>> More on this.
>> 
>> I find when I look a the deployment yaml that the volume ends up looking 
>> like this:
>> 
>>   volumes:
>> - configMap:
>> defaultMode: 420
>> name: squonk-sso-config
>>   name: squonk-sso-config
>> 
>> This is despite `oc explain pod.spec.volumes.configMap` stating that the 
>> default for defaultMode is 0644.
>> 
>> Even when I specify defaultMode: 0644 in the template it ends up being 
>> 420.
>> 
>> Any idea what's going on?
>> 
>> 
>> On 08/12/17 16:44, Tim Dudgeon wrote:
>>> Hi All,
>>> 
>>> I'm having a problem mounting a file from a ConfigMap when running on 
>>> an Openshift origin environment, but when doing the same on Minishift 
>>> it works fine.
>>> 
>>> I'm mounting the context.xml file from the ConfigMap into the container 
>>> like this:
>>> 
>>>   spec:
>>> containers:
>>> - image: ...
>>>   ...
>>>   volumeMounts:
>>> - mountPath: 
>>> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>>>   name: my-configmap-vol
>>>   subPath: context.xml
>>>   readOnly: true
>>> volumes:
>>>   - name: my-configmap-vol
>>> configMap:
>>>

Re: Permissions problem mounting file from ConfigMap

2017-12-13 Thread Joel Pearson 
Oh, I didn't realise configmaps got updated without a Pod restart.  How
long does it take to update?  I see in (
https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#mounted-configmaps-are-updated-automatically)
it says the kubelet sync period + ttl.  What are the OpenShift defaults for
that?

On Wed, Dec 13, 2017 at 8:41 PM Graham Dumpleton 
wrote:

> If you copy it rather than symlink, you will loose the ability that an
> update to the configmap will be reflected automatically inside of the
> container after a short period. If the file was something that was
> rescanned by the application, this allows changes to be pushed into a
> container without needing to do a restart. If you only read the file once
> on start up, then copying would be fine.
>
> Graham
>
>
>
> On 13 Dec 2017, at 8:26 pm, Tim Dudgeon  wrote:
>
> Graham,
>
> Thanks for your help on this.
> I had managed to work around the problem in a way similar to how you
> described (but copying not symlinking). Not nice, but it works!
>
> On 12/12/17 21:10, Graham Dumpleton wrote:
>
> A belated update on this.
>
> The problem with using subPath is due to a SELinux issue in the kernel.
>
> There is an issue about it at:
>
> https://github.com/openshift/origin/issues/16951
>
> Whether you see it will depend on how SELinux is setup I guess.
>
> The only work around would be to mount it as a directory '..data' in the
> target directory, and then you create a symlink from startup run script in
> your source code to symlink the file in the '..data' directory into the
> parent. Know of no other solution at this point.
>
> Graham
>
> On 9 Dec 2017, at 8:36 pm, Tim Dudgeon  wrote:
>
> If you mount onto a new directory you get the same problem.
> It only seems to happen when specifying a subPath as follows:
>
> - mountPath:
> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>   name: squonk-sso-config
>   subPath: context.xml
>   readOnly: true
>
> If the whole configMap is mounted to a directory the contents are readable.
>
> And as mentioned already, if you do this in Minishift it works fine.
>
>
> On 09/12/17 02:16, Graham Dumpleton wrote:
>
> The permissions is correct. It is shown as decimal, not the octal you are
> setting it with.
>
> '%o' % 420
>
> '644'
>
> What happens when you mount the configmap onto a directory separate from
> anything else?
>
> Graham
>
> On 9 Dec 2017, at 4:02 am, Tim Dudgeon  wrote:
>
> More on this.
>
> I find when I look a the deployment yaml that the volume ends up looking
> like this:
>
>   volumes:
> - configMap:
> defaultMode: 420
> name: squonk-sso-config
>   name: squonk-sso-config
>
> This is despite `oc explain pod.spec.volumes.configMap` stating that the
> default for defaultMode is 0644.
>
> Even when I specify defaultMode: 0644 in the template it ends up being 420.
>
> Any idea what's going on?
>
>
> On 08/12/17 16:44, Tim Dudgeon wrote:
>
> Hi All,
>
> I'm having a problem mounting a file from a ConfigMap when running on an
> Openshift origin environment, but when doing the same on Minishift it works
> fine.
>
> I'm mounting the context.xml file from the ConfigMap into the container
> like this:
>
>   spec:
> containers:
> - image: ...
>   ...
>   volumeMounts:
> - mountPath:
> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>   name: my-configmap-vol
>   subPath: context.xml
>   readOnly: true
> volumes:
>   - name: my-configmap-vol
> configMap:
>   name: squonk-sso-config
>
> Within the container the file is there but has permissions problems:
>
> # ls -l
> ls: cannot access 'context.xml': Permission denied
> total 4
> -rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
> -?? ? ??  ?? context.xml
>
> Any idea what's the problem?
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
>
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Permissions problem mounting file from ConfigMap

2017-12-13 Thread Graham Dumpleton 
If you copy it rather than symlink, you will loose the ability that an update 
to the configmap will be reflected automatically inside of the container after 
a short period. If the file was something that was rescanned by the 
application, this allows changes to be pushed into a container without needing 
to do a restart. If you only read the file once on start up, then copying would 
be fine.

Graham


> On 13 Dec 2017, at 8:26 pm, Tim Dudgeon  wrote:
> 
> Graham,
> 
> Thanks for your help on this.
> I had managed to work around the problem in a way similar to how you 
> described (but copying not symlinking). Not nice, but it works! 
> 
> On 12/12/17 21:10, Graham Dumpleton wrote:
>> A belated update on this.
>> 
>> The problem with using subPath is due to a SELinux issue in the kernel.
>> 
>> There is an issue about it at:
>> 
>> https://github.com/openshift/origin/issues/16951 
>> 
>> 
>> Whether you see it will depend on how SELinux is setup I guess.
>> 
>> The only work around would be to mount it as a directory '..data' in the 
>> target directory, and then you create a symlink from startup run script in 
>> your source code to symlink the file in the '..data' directory into the 
>> parent. Know of no other solution at this point.
>> 
>> Graham
>> 
>>> On 9 Dec 2017, at 8:36 pm, Tim Dudgeon >> > wrote:
>>> 
>>> If you mount onto a new directory you get the same problem.
>>> It only seems to happen when specifying a subPath as follows:
>>> 
>>> - mountPath: 
>>> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>>>   name: squonk-sso-config
>>>   subPath: context.xml
>>>   readOnly: true
>>> 
>>> If the whole configMap is mounted to a directory the contents are readable.
>>> 
>>> And as mentioned already, if you do this in Minishift it works fine.
>>> 
>>> 
>>> On 09/12/17 02:16, Graham Dumpleton wrote:
 The permissions is correct. It is shown as decimal, not the octal you are 
 setting it with.
 
>>> '%o' % 420
 '644'
 
 What happens when you mount the configmap onto a directory separate from 
 anything else?
 
 Graham
 
> On 9 Dec 2017, at 4:02 am, Tim Dudgeon  > wrote:
> 
> More on this.
> 
> I find when I look a the deployment yaml that the volume ends up looking 
> like this:
> 
>   volumes:
> - configMap:
> defaultMode: 420
> name: squonk-sso-config
>   name: squonk-sso-config
> 
> This is despite `oc explain pod.spec.volumes.configMap` stating that the 
> default for defaultMode is 0644.
> 
> Even when I specify defaultMode: 0644 in the template it ends up being 
> 420.
> 
> Any idea what's going on?
> 
> 
> On 08/12/17 16:44, Tim Dudgeon wrote:
>> Hi All,
>> 
>> I'm having a problem mounting a file from a ConfigMap when running on an 
>> Openshift origin environment, but when doing the same on Minishift it 
>> works fine.
>> 
>> I'm mounting the context.xml file from the ConfigMap into the container 
>> like this:
>> 
>>   spec:
>> containers:
>> - image: ...
>>   ...
>>   volumeMounts:
>> - mountPath: 
>> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>>   name: my-configmap-vol
>>   subPath: context.xml
>>   readOnly: true
>> volumes:
>>   - name: my-configmap-vol
>> configMap:
>>   name: squonk-sso-config
>> 
>> Within the container the file is there but has permissions problems:
>> 
>> # ls -l
>> ls: cannot access 'context.xml': Permission denied
>> total 4
>> -rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
>> -?? ? ??  ?? context.xml
>> 
>> Any idea what's the problem?
>> 
> ___
> users mailing list
> users@lists.openshift.redhat.com 
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users 
> 
>>> 
>> 
> 
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users

___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Permissions problem mounting file from ConfigMap

2017-12-13 Thread Tim Dudgeon 

Graham,

Thanks for your help on this.
I had managed to work around the problem in a way similar to how you 
described (but copying not symlinking). Not nice, but it works!



On 12/12/17 21:10, Graham Dumpleton wrote:

A belated update on this.

The problem with using subPath is due to a SELinux issue in the kernel.

There is an issue about it at:

https://github.com/openshift/origin/issues/16951

Whether you see it will depend on how SELinux is setup I guess.

The only work around would be to mount it as a directory '..data' in 
the target directory, and then you create a symlink from startup run 
script in your source code to symlink the file in the '..data' 
directory into the parent. Know of no other solution at this point.


Graham

On 9 Dec 2017, at 8:36 pm, Tim Dudgeon > wrote:


If you mount onto a new directory you get the same problem.
It only seems to happen when specifying a subPath as follows:

    - mountPath: 
/usr/local/tomcat/webapps/portal/META-INF/context.xml

  name: squonk-sso-config
  subPath: context.xml
  readOnly: true

If the whole configMap is mounted to a directory the contents are 
readable.


And as mentioned already, if you do this in Minishift it works fine.


On 09/12/17 02:16, Graham Dumpleton wrote:
The permissions is correct. It is shown as decimal, not the octal 
you are setting it with.



'%o' % 420

'644'

What happens when you mount the configmap onto a directory separate 
from anything else?


Graham

On 9 Dec 2017, at 4:02 am, Tim Dudgeon > wrote:


More on this.

I find when I look a the deployment yaml that the volume ends up 
looking like this:


  volumes:
- configMap:
defaultMode: 420
name: squonk-sso-config
  name: squonk-sso-config

This is despite `oc explain pod.spec.volumes.configMap` stating 
that the default for defaultMode is 0644.


Even when I specify defaultMode: 0644 in the template it ends up 
being 420.


Any idea what's going on?


On 08/12/17 16:44, Tim Dudgeon wrote:

Hi All,

I'm having a problem mounting a file from a ConfigMap when running 
on an Openshift origin environment, but when doing the same on 
Minishift it works fine.


I'm mounting the context.xml file from the ConfigMap into the 
container like this:


  spec:
containers:
- image: ...
  ...
  volumeMounts:
- mountPath: 
/usr/local/tomcat/webapps/portal/META-INF/context.xml

  name: my-configmap-vol
  subPath: context.xml
  readOnly: true
volumes:
  - name: my-configmap-vol
configMap:
  name: squonk-sso-config

Within the container the file is there but has permissions problems:

# ls -l
ls: cannot access 'context.xml': Permission denied
total 4
-rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
-?? ? ?    ?  ?    ? context.xml

Any idea what's the problem?


___
users mailing list
users@lists.openshift.redhat.com 


http://lists.openshift.redhat.com/openshiftmm/listinfo/users






___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Permissions problem mounting file from ConfigMap

2017-12-12 Thread Graham Dumpleton 
A belated update on this.

The problem with using subPath is due to a SELinux issue in the kernel.

There is an issue about it at:

https://github.com/openshift/origin/issues/16951 


Whether you see it will depend on how SELinux is setup I guess.

The only work around would be to mount it as a directory '..data' in the target 
directory, and then you create a symlink from startup run script in your source 
code to symlink the file in the '..data' directory into the parent. Know of no 
other solution at this point.

Graham

> On 9 Dec 2017, at 8:36 pm, Tim Dudgeon  wrote:
> 
> If you mount onto a new directory you get the same problem.
> It only seems to happen when specifying a subPath as follows:
> 
> - mountPath: /usr/local/tomcat/webapps/portal/META-INF/context.xml
>   name: squonk-sso-config
>   subPath: context.xml
>   readOnly: true
> 
> If the whole configMap is mounted to a directory the contents are readable.
> 
> And as mentioned already, if you do this in Minishift it works fine.
> 
> 
> On 09/12/17 02:16, Graham Dumpleton wrote:
>> The permissions is correct. It is shown as decimal, not the octal you are 
>> setting it with.
>> 
> '%o' % 420
>> '644'
>> 
>> What happens when you mount the configmap onto a directory separate from 
>> anything else?
>> 
>> Graham
>> 
>>> On 9 Dec 2017, at 4:02 am, Tim Dudgeon  wrote:
>>> 
>>> More on this.
>>> 
>>> I find when I look a the deployment yaml that the volume ends up looking 
>>> like this:
>>> 
>>>   volumes:
>>> - configMap:
>>> defaultMode: 420
>>> name: squonk-sso-config
>>>   name: squonk-sso-config
>>> 
>>> This is despite `oc explain pod.spec.volumes.configMap` stating that the 
>>> default for defaultMode is 0644.
>>> 
>>> Even when I specify defaultMode: 0644 in the template it ends up being 420.
>>> 
>>> Any idea what's going on?
>>> 
>>> 
>>> On 08/12/17 16:44, Tim Dudgeon wrote:
 Hi All,
 
 I'm having a problem mounting a file from a ConfigMap when running on an 
 Openshift origin environment, but when doing the same on Minishift it 
 works fine.
 
 I'm mounting the context.xml file from the ConfigMap into the container 
 like this:
 
   spec:
 containers:
 - image: ...
   ...
   volumeMounts:
 - mountPath: 
 /usr/local/tomcat/webapps/portal/META-INF/context.xml
   name: my-configmap-vol
   subPath: context.xml
   readOnly: true
 volumes:
   - name: my-configmap-vol
 configMap:
   name: squonk-sso-config
 
 Within the container the file is there but has permissions problems:
 
 # ls -l
 ls: cannot access 'context.xml': Permission denied
 total 4
 -rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
 -?? ? ??  ?? context.xml
 
 Any idea what's the problem?
 
>>> ___
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
> 

___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Permissions problem mounting file from ConfigMap

2017-12-09 Thread Tim Dudgeon 

If you mount onto a new directory you get the same problem.
It only seems to happen when specifying a subPath as follows:

    - mountPath: 
/usr/local/tomcat/webapps/portal/META-INF/context.xml

  name: squonk-sso-config
  subPath: context.xml
  readOnly: true

If the whole configMap is mounted to a directory the contents are readable.

And as mentioned already, if you do this in Minishift it works fine.


On 09/12/17 02:16, Graham Dumpleton wrote:

The permissions is correct. It is shown as decimal, not the octal you are 
setting it with.


'%o' % 420

'644'

What happens when you mount the configmap onto a directory separate from 
anything else?

Graham


On 9 Dec 2017, at 4:02 am, Tim Dudgeon  wrote:

More on this.

I find when I look a the deployment yaml that the volume ends up looking like 
this:

   volumes:
 - configMap:
 defaultMode: 420
 name: squonk-sso-config
   name: squonk-sso-config

This is despite `oc explain pod.spec.volumes.configMap` stating that the 
default for defaultMode is 0644.

Even when I specify defaultMode: 0644 in the template it ends up being 420.

Any idea what's going on?


On 08/12/17 16:44, Tim Dudgeon wrote:

Hi All,

I'm having a problem mounting a file from a ConfigMap when running on an 
Openshift origin environment, but when doing the same on Minishift it works 
fine.

I'm mounting the context.xml file from the ConfigMap into the container like 
this:

   spec:
 containers:
 - image: ...
   ...
   volumeMounts:
 - mountPath: /usr/local/tomcat/webapps/portal/META-INF/context.xml
   name: my-configmap-vol
   subPath: context.xml
   readOnly: true
 volumes:
   - name: my-configmap-vol
 configMap:
   name: squonk-sso-config

Within the container the file is there but has permissions problems:

# ls -l
ls: cannot access 'context.xml': Permission denied
total 4
-rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
-?? ? ??  ?? context.xml

Any idea what's the problem?


___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Permissions problem mounting file from ConfigMap

2017-12-08 Thread Graham Dumpleton 
The permissions is correct. It is shown as decimal, not the octal you are 
setting it with.

>>> '%o' % 420
'644'

What happens when you mount the configmap onto a directory separate from 
anything else?

Graham

> On 9 Dec 2017, at 4:02 am, Tim Dudgeon  wrote:
> 
> More on this.
> 
> I find when I look a the deployment yaml that the volume ends up looking like 
> this:
> 
>   volumes:
> - configMap:
> defaultMode: 420
> name: squonk-sso-config
>   name: squonk-sso-config
> 
> This is despite `oc explain pod.spec.volumes.configMap` stating that the 
> default for defaultMode is 0644.
> 
> Even when I specify defaultMode: 0644 in the template it ends up being 420.
> 
> Any idea what's going on?
> 
> 
> On 08/12/17 16:44, Tim Dudgeon wrote:
>> Hi All,
>> 
>> I'm having a problem mounting a file from a ConfigMap when running on an 
>> Openshift origin environment, but when doing the same on Minishift it works 
>> fine.
>> 
>> I'm mounting the context.xml file from the ConfigMap into the container like 
>> this:
>> 
>>   spec:
>> containers:
>> - image: ...
>>   ...
>>   volumeMounts:
>> - mountPath: 
>> /usr/local/tomcat/webapps/portal/META-INF/context.xml
>>   name: my-configmap-vol
>>   subPath: context.xml
>>   readOnly: true
>> volumes:
>>   - name: my-configmap-vol
>> configMap:
>>   name: squonk-sso-config
>> 
>> Within the container the file is there but has permissions problems:
>> 
>> # ls -l
>> ls: cannot access 'context.xml': Permission denied
>> total 4
>> -rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
>> -?? ? ??  ?? context.xml
>> 
>> Any idea what's the problem?
>> 
> 
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users


___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: Permissions problem mounting file from ConfigMap

2017-12-08 Thread Tim Dudgeon 

More on this.

I find when I look a the deployment yaml that the volume ends up looking 
like this:


  volumes:
    - configMap:
    defaultMode: 420
    name: squonk-sso-config
  name: squonk-sso-config

This is despite `oc explain pod.spec.volumes.configMap` stating that the 
default for defaultMode is 0644.


Even when I specify defaultMode: 0644 in the template it ends up being 420.

Any idea what's going on?


On 08/12/17 16:44, Tim Dudgeon wrote:

Hi All,

I'm having a problem mounting a file from a ConfigMap when running on 
an Openshift origin environment, but when doing the same on Minishift 
it works fine.


I'm mounting the context.xml file from the ConfigMap into the 
container like this:


  spec:
    containers:
    - image: ...
  ...
  volumeMounts:
    - mountPath: 
/usr/local/tomcat/webapps/portal/META-INF/context.xml

  name: my-configmap-vol
  subPath: context.xml
  readOnly: true
    volumes:
  - name: my-configmap-vol
    configMap:
  name: squonk-sso-config

Within the container the file is there but has permissions problems:

# ls -l
ls: cannot access 'context.xml': Permission denied
total 4
-rw-r--r--. 1 root root 104 Dec  5 12:48 MANIFEST.MF
-?? ? ?    ?  ?    ? context.xml

Any idea what's the problem?



___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users