Hi, I'm using gt4.2.1.
Now after restart two globus-ws-java-container, it's strange that the owner
is seem to be ok now.
However, still following problem :
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:bd5ac64a-0fab-11de-84dc-0011258c5df2
Termination time: 03/13/3009 08:44 GMT
Current job state: Failed
Destroying job...Done.
Cleaning up any delegated credentials...Done.
globusrun-ws: Job failed: Staging error for RSL element fileStageIn. Setting
permissions on /home/griduser1/grid/myhello.sh failed on server
cm.mydomain.com [Caused by: Server refused performing the request. Custom
message: (error code 1) [Nested exception message: Custom message:
Unexpected reply: 500-Command failed : System error in chmod: Operation not
permitted
500-A system call failed: Operation not permitted
500 End.]]
here is my job :
<job>
<factoryEndpoint>
<wsa:Address>
https://cm.mydomain.com:8443/wsrf/services/ManagedJobFactoryService
</wsa:Address>
</factoryEndpoint>
<executable>/bin/sh</executable>
<argument>/home/griduser1/grid/dir/myhello.sh</argument>
<count>1</count>
<fileStageIn>
<transfer>
<sourceUrl>
gsiftp://
client.mydomain.com:2811/home/griduser1/grid/myhello
</sourceUrl>
<destinationUrl>
gsiftp://
cm.mydomain.com:2811/home/griduser1/grid/dir/myhello.sh</destinationUrl>
</transfer>
</fileStageIn>
</job>
My two machines share a common /home directory and NIS.
And here is my gsiftp configuration:
GridFTP
File : /etc/xinetd.d/gridftp
service gsiftp
{
instances = 100
socket_type = stream
wait = no
user = root # <---- Notice this user, it has to be
matched with the /etc/grid-security/hostcert.pem owner
env += GLOBUS_LOCATION=/opt/gt4.2.1
env += LD_LIBRARY_PATH=/opt/gt4.2.1/lib
server = /opt/gt4.2.1/sbin/globus-gridftp-server
server_args = -i
log_on_success += DURATION
nice = 10
disable = no}
On Thu, Mar 12, 2009 at 9:22 PM, John Bresnahan <[email protected]>wrote:
> hmmm, this seems very strange. can you send the configuration options used
> on the gridftp server?
>
>
> Le Trung Kien wrote:
>
>> Thank you,
>> With globus-url-copy I saw that the owner of the duplicate is right the
>> globus mapped user.
>> Maybe this case harder ? please, help.
>>
>>
>> On Wed, Mar 11, 2009 at 7:43 PM, Martin Feller <[email protected]>
>> wrote:
>>
>> Does the same happen if you use globus-url-copy to transfer
>>> a file, instead of using GridFTP via ws-gram?
>>> (globus-url-copy \
>>> gsiftp://client.mydomain.com:2811/home/griduser1/grid/myhello \
>>> gsiftp://cm.mydomain.com:2811/tmp/myhello)
>>>
>>> I assume so, and this would help narrowing it down.
>>>
>>> -Martin
>>>
>>> Le Trung Kien wrote:
>>>
>>>> Hi,
>>>> In my job description, I define a fileStageIn like this
>>>>
>>>> <fileStageIn>
>>>> <transfer>
>>>> <sourceUrl>gsiftp://
>>>> client.mydomain.com:2811/home/griduser1/grid/myhello</sourceUrl>
>>>> <destinationUrl>gsiftp://cm.mydomain.com:2811/tmp/myhello
>>>> </destinationUrl>
>>>> </transfer>
>>>> </fileStageIn>
>>>>
>>>> After submitting my job, I got the file delivered, but it's strange that
>>>>
>>> on
>>>
>>>> cm.mydomain.com
>>>>
>>>> gridus...@cm #] ls -l /tmp/myhello
>>>> -rwxr-xr-x 1 root root 147 Mar 9 16:02 /tmp/myhello
>>>>
>>>> We see that this file is owned by root.
>>>> In fact, with this problem I couldn't copy files and execute the files
>>>>
>>> with
>>>
>>>> right permission on my user's directories.
>>>> Additional information :
>>>> In my grid-mapfile, I have only one mapping from grid user to local user
>>>> (this local user in my case is a NIS account).
>>>>
>>>> Help me, please.
>>>>
>>>>
>>>
>>
>>
>
--
Le Trung Kien.