$ edg-rm --vo dteam cr file:/etc/group -d cmsdcdr3.fnal.gov
VO not supported on Host : cmsdcdr3.fnal.gov

  $ lcg-cr --vo dteam  file:/etc/group -d cmsdcdr3.fnal.gov
lcg_cr: Invalid argument

Note:

It could be entirley correct that the VO is actually not supported at a particular SE.

2. Diagnosis

1. Perform an ldapsearch of the site GIIS to see which VOs can access a GlueSA.

   	   $ ldapsearch -h ldap://hotdog46.fnal.gov:2135 -b mds-vo-name=fnallcg2,o=grid  \
   	'(objectClass=GlueSA)' GlueSARoot GlueSAAccessControlBaseRule GlueChunkKey GlueSEName
   	dn: GlueSARoot=cms:/pnfs/fnal.gov/usr/cms,GlueSEUniqueID=cmsdcdr3.fnal.gov,Mds-Vo-name=fnallcg2,o=grid
   	GlueSARoot: cms:/pnfs/fnal.gov/usr/cms
   	GlueSAAccessControlBaseRule: cms
   	GlueChunkKey: GlueSEUniqueID=cmsdcdr3.fnal.gov
   	GlueSEName: cmsdcdr3:srm_v1
   	

2. 	If the GlueSEName is *:srm_v1 or *:edg-se then a pattern match is done of the GlueSEUniqueID to find the GlueServiceURI for the SE. In this case cmsdcdr3.fnal.gov Perform an ldapsearch of the site GIIS to see which VOs can access the SE's GlueServiceURI. 
   	

   	   $ ldapsearch -x -H ldap://hotdog46.fnal.gov:2135 -b mds-vo-name=fnallcg2,o=grid \
   	'(GlueServiceURI=httpg://cmsdcdr3.fnal.gov:8443/srm/managerv1)' GlueServiceURI GlueServiceAccessControlRule
   	dn: GlueServiceURI=httpg://cmsdcdr3.fnal.gov:8443/srm/managerv1,Mds-Vo-name=fnallcg2,o=grid
   	GlueServiceURI: httpg://cmsdcdr3.fnal.gov:8443/srm/managerv1
   	GlueServiceAccessControlRule: cms
   	dn: GlueServiceURI=httpg://cmsdcdr3.fnal.gov:8443/srm/managerv1,Mds-Vo-name=fnallcg2,o=grid
   	GlueServiceURI: httpg://cmsdcdr3.fnal.gov:8443/srm/managerv1
   	GlueServiceAccessControlRule: atlas
   	dn: GlueServiceURI=httpg://cmsdcdr3.fnal.gov:8443/srm/managerv1,Mds-Vo-name=fnallcg2,o=grid
   	GlueServiceURI: httpg://cmsdcdr3.fnal.gov:8443/srm/managerv1
   	GlueServiceAccessControlRule: dteam
   	

3. What we see in this case is inconsistancy between the VOs able to access the storage area and the VOs that can access the service. End users cannot use this type of service if they cannot access the storage area.
4. It may be possible to add this as a sanity check within the gstat framework, this is not currently implemented.

3. Solution

$ lcg-rep --vo dteam lfn:my-test-lfn -d my-SE.my-domain
the server sent an error response: 425 425 Can't open data connection. timed out() failed.

2. Diagnosis

Typical scenario: on a WN, lcg-rep from a remote SE to the close/default SE fails.

This can have various causes:

1. At the time of the command the target SE or LFC node was down/unreachable from outside, or it is not allowed by any firewall on the way.

2. The GLOBUS_TCP_PORT_RANGE is not defined on the target SE, or the range is not allowed by a firewall in front of the target SE.

3. Some firewall between the WN and either SE has a problem with connections in rapid succession that all use the same source and destination ports, i.e. rapidly repeating occurrences of WN:20000 --> SE:2811, WN:20001 --> SE:20000, which are typical when the WN tries to copy a file onto the SE.

3. Solution

The idea is that normally the port on the WN will be assigned by the OS to a different value for each connection, and then the firewall would conclude that the repeated connection is abnormal/illegal, so should be blocked.

The whole issue can be avoided by unsetting GLOBUS_TCP_PORT_RANGE on the WN, such that the OS will indeed assign a different source port each time.

A data management command fails with:

VO_<voname>_DEFAULT_SE undefined.

2. Diagnosis

This environment variable is obtained from the YAIM parameter VO_DTEAM_DEFAULT_SE.

This in turns configures the system environment variables defined here:

/etc/profile.d/lcgenv.csh
/etc/profile.d/lcgenv.sh

For example

export VO_DTEAM_DEFAULT_SE=some_se.grid.edu

3. Solution

Configure the YAIM parameter correct and rerun YAIM or manually define the variables in the environment scripts.

lcg-cr fails with the folloing error:

+ lcg-cr -v --vo dteam -d <someSE> -l lfn:/grid/dteam/SFT/lfnname file:///home/dteam002/testfile.txt

LFC endpoint not found
LFC endpoint not found
lcg_cr: Invalid argument
Using grid catalog type: lfc
Using grid catalog : (null)
+ result=1
+ set +x

2. Diagnosis

1. -d parameter gets invalid hostname

2. variable LCG_GFAL_INFOSYS is not defined correctly

3. SE given as a parameter for -d option is not available

4. SE not present in the top-level BDII pointed to by LCG_GFAL_INFOSYS

5. Will also print following error message SE type not found

3. Solution

set LCG_GFAL_INFOSYS to point to a top-level BDII

Also see undefined VO SE