I just tried to reproduce your problem:

allcock@gridftp:~> ll /home/bresnaha/for_bill
-rw-rw----  1 bresnaha users 0 2005-08-04 12:15 /home/bresnaha/for_bill
allcock@gridftp:~> groups
users uucp dialout audio video
allcock@gridftp:~> whoami
allcock
allcock@gridftp:~> guc gsiftp://localhost/home/bresnaha/for_bill
gsiftp://localhost/tmp/deleteme     
allcock@gridftp:~> guc file:///home/bresnaha/for_bill
gsiftp://localhost/tmp/deleteme   allcock@gridftp:~> guc
gsiftp://localhost/home/bresnaha/for_bill file:///tmp/deleteme  
allcock@gridftp:~> guc file:///home/bresnaha/for_bill file:///tmp/deleteme     
        
allcock@gridftp:~> guc -p 2 gsiftp://localhost/home/bresnaha/for_bill
gsiftp://localhost/tmp/deleteme
allcock@gridftp:~> guc -p 2 file:///home/bresnaha/for_bill
gsiftp://localhost/tmp/deleteme
allcock@gridftp:~> guc -p 2 gsiftp://localhost/home/bresnaha/for_bill
file:///tmp/deleteme
allcock@gridftp:~> guc -p 2 file:///home/bresnaha/for_bill file:///tmp/deleteme
        allcock@gridftp:~> 

I tried both MODE S (no -p) and MODE E (-p) with all combinations of file: and
gsiftp: (which ultimately should not matter, but you never know)

Could you please send us your OS Distro, the full command line, the error,
grid-cert-info -subject output, and the entry for that subject in the gridmap
file on the host where the server and target file are?  My best guess is that
the server is not running as you and does not have permissions on the file.

[slanzarini@pc-slanzarini tmp]$ ll /tmp/provaRFT.txt
-rw-rw----  1 tomcat tomcat 10  4 ago 18:58 /tmp/provaRFT.txt
[slanzarini@pc-slanzarini tmp]$ groups
slanzarini unicore globus postgres tomcat developer
[slanzarini@pc-slanzarini tmp]$ whoami
slanzarini



My DISTRO is Fedora Core 3, kernel: 2.6.11-1.35_FC3, but i get the same error
with a Linux SuSE SLES 8, kernel 2.4.21-286-smp

[slanzarini@pc-slanzarini tmp]$ globus-url-copy
gsiftp://pc-slanzarini.cineca.it:2811/tmp/provaRFT.txt
gsiftp://pc-slanzarini.cineca.it:2811/home/slanzarini/445566.txt


error: globus_ftp_client: the server responded with an error
500 500-Command failed. : globus_l_gfs_file_open failed.
500-globus_xio: Unable to open file /tmp/provaRFT.txt
500-globus_xio: System error in open: Permission denied
500-globus_xio: A system call failed: Permission denied
500 End.


I need to set it as a "3rd party transfer" syntax, since actually I've to move
the data using RFT.

If I set the guc command as follows, it works fine:
[slanzarini@pc-slanzarini tmp]$ globus-url-copy file:///tmp/provaRFT.txt
gsiftp://pc-slanzarini.cineca.it:2811/home/slanzarini/445566.txt

The following gives me the same error as above:
[slanzarini@pc-slanzarini tmp]$ globus-url-copy
gsiftp://localhost/tmp/provaRFT.txt
gsiftp://pc-slanzarini.cineca.it:2811/home/slanzarini/445566.txt

error: globus_ftp_client: the server responded with an error
500 500-Command failed. : globus_l_gfs_file_open failed.
500-globus_xio: Unable to open file /tmp/provaRFT.txt
500-globus_xio: System error in open: Permission denied
500-globus_xio: A system call failed: Permission denied
500 End.

I've tried also a transfer with parallel stream s:

[slanzarini@pc-slanzarini tmp]$ globus-url-copy -p 2
gsiftp://localhost/tmp/provaRFT.txt
gsiftp://pc-slanzarini.cineca.it:2811/home/slanzarini/445566.txt

error: globus_ftp_client: the server responded with an error
500 500-Command failed. : globus_l_gfs_file_open failed.
500-globus_xio: Unable to open file /tmp/provaRFT.txt
500-globus_xio: System error in open: Permission denied
500-globus_xio: A system call failed: Permission denied
500 End.

[slanzarini@pc-slanzarini tmp]$ grid-cert-info -subject
/O=Cineca/O=Grid/OU=grid.cineca.it/OU=cineca.it/CN=Simone Lanzarini

[slanzarini@pc-slanzarini tmp]$ more /etc/grid-security/grid-mapfile
"/O=Cineca/O=Grid/OU=grid.cineca.it/OU=cineca.it/CN=Simone Lanzarini" slanzarini

Very odd... The fact that it works when you use file: means that your client
process (globus-url-copy) has read access, but the server does not, but based on
your gridmap, I can't see why.

Could you please run the globus-url-copy again (the one that fails) with -dbg? 
Also, could you send the xinetd config files and gridftp config files, if any? 
I am still inclined to believe that the server is not running in the right
account.  We just do the posix file open, based on the process uid and gid, the
OS either says yes or no, and it says yes to globus-url-copy and no to the
server, but the debug will tell us who you are being logged in, so we shall see.
 btw, just to make sure I have this right, this is all happening on a single
machine, right?

Created an attachment (id=663) [details]
globus-url-copy command with debug enabled

In my previous messagge I attached the output of the following command:
[slanzarini@pc-slanzarini tmp]$ globus-url-copy -dbg
gsiftp://pc-slanzarini.cineca.it:2811/tmp/provaRFT.txt
gsiftp://pc-slanzarini.cineca.it:2811/home/slanzarini/445566.txt

Here's my xinetd file:

[slanzarini@pc-slanzarini tmp]$ more /etc/xinetd.d/gridftp
service gsiftpd
{
  instances             = 1000
  socket_type           = stream
  wait                  = no
  user                  = root
  env                   += GLOBUS_LOCATION=/opt/grid/globus/globus
  env                   += LD_LIBRARY_PATH=/opt/grid/globus/globus/lib
  env                   +=
PATH=/opt/grid/globus/globus/sbin:/opt/grid/globus/globus/bin
  server                = /opt/grid/globus/globus/sbin/globus-gridftp-server
  server_args           = -i -c /opt/grid/globus/gridftp.conf
  port                  = 2811
  log_on_success        += DURATION USERID
  log_on_failure        += USERID
  nice                  = 10
  disable               = no
}

Here's the config file (even if it has nothing of interesting, I suppose):

[slanzarini@pc-slanzarini tmp]$ more /opt/grid/globus/gridftp.conf
log-level all
log_single /var/log/gridftp/gridftp.log
log_transfer /var/log/gridftp/gridftp-transfers.log


Yes, all this is happening on a single machine, but I obtain the same behaviour
using another machine (with its own server installation), a Linux SuSE SLES 8,
kernel 2.4.21-286-smp with gtk 4.0.0 (gridftp server version 2.0), or even
performing the guc command from a 3rd party machine, and setting the destination
url to a machine different from pc-slanzarini

I don't know if it can be useful, but the following is a snippet of my gridftp
server log, corresponding to the command performed above, it seems to be
executed with the proper user, insn't it?

DATE=20050804205919.948539 HOST=pc-slanzarini.cineca.it
PROG=globus-gridftp-server NL.EVNT=FTP_INFO START=20050804205919.792794
USER=slanzarini FILE=/home/slanzarini/445566.txt BUFFER=0 BLOCK=262144 NBYTES=0
VOLUME=/ STREAMS=1 STRIPES=1 DEST=[0.0.0.0] TYPE=STOR CODE=226
[slanzarini@pc-slanzarini tmp]$

I'm able to reproduce this.  I'm not sure yet why, but the problem comes when 
the owning group isn't the user's default group.  I'm looking in to it.

Created an attachment (id=664) [details]
patch to globus_gridftp_server 4.0.1 release

attaching patch for the upcoming 4.0.1 release.  This works on linux, I still
need to test and verify on other platforms as I'm not sure about the
portability of the initgroups() call.

This patch also seems to fix a bug where GridFTP was not writing a file to a
directory owned by a group which was not the default group of the user (but a
group that the user did belong to).

Fix included with 4.0.2 release.