Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @


From EGIWiki
Jump to navigation Jump to search
Main operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security

Documentation menu: Home Manuals Procedures Training Other Contact For: VO managers Administrators

Back to Troubleshooting Guide

530 530 No local mapping for Globus ID

NOTE: various items on this page are historical and hence no longer relevant.


  1. A proxy with expired VOMS attributes was refused ("Login incorrect").
  2. Server has wrong VOMS configuration for VO.
  3. Problem in /etc/grid-security/grid-mapfile
  4. Problem in /etc/grid-security/groupmapfile (for VOMS mapping)
  5. Problem in /opt/glite/etc/lcmaps/{grid,group}mapfile (Quattor setup)
  6. Problem with pool accounts
  7. Problem with /etc/grid-security/gridmapdir
  8. Files for pool accounts absent from /etc/grid-security/gridmapdir
  9. Variable GRIDMAPDIR is not set correctly. Gatekeeper and GridFTP daemon need this to be able to use pool accounts, else only static accounts (like dteamsgm) work.
  10. GridFTP daemon does not have LCMAPS_DB_FILE properly defined.
  11. No free pool account in the correct set
  12. Stale entries in /etc/grid-security/gridmapdir
  13. DN is banned in /opt/glite/etc/lcas/ban_users.db
  14. Check {grid-,group}mapfile, gridmapdir, mapping policies of the Argus host (if used).

On the LCG-CE and other gLite services one may also want to check these files, whose contents normally are hardcoded by YAIM or Quattor:



  • If one of these commands
 uberftp server.domain pwd
 globus-url-copy file:/etc/group gsiftp://server.domain/tmp/foo.$$
complains about CRLs in its long output, look here.
  • To support VOMS proxies for a VO, the service must either have a copy of the host certificate(s) of the VOMS server(s) used by the VO in /etc/grid-security/vomsdir/ (still needed on FTS and WMS, file names must end in .pem on FTS), or the directory /etc/grid-security/vomsdir/$vo needs to have a file fqhn.lsc (fqhn = fully qualified hostname) for every VOMS server used by the VO. Note: the VOMS client code takes the fqhn from the uri attribute reported by voms-proxy-info (see below). Each such file shall contain 2 lines: the first line consists of the host certificate DN (without quotes), the second line consists of the DN of the CA that issued the certificate (without quotes). For example:
 [root@ce dteam]# pwd
 [root@ce dteam]# ls -l
 total 8
 -rw-r--r-- 1 root root 128 Sep 16 16:07
 -rw-r--r-- 1 root root 129 Sep 16 16:07
 [root@ce dteam]# cat 
 /C=GR/O=HellasGrid/OU=Certification Authorities/CN=HellasGrid CA 2006
 [root@ce dteam]# cat 
 /C=GR/O=HellasGrid/OU=Certification Authorities/CN=HellasGrid CA 2006
 $ voms-proxy-info -uri
The "uri" attribute can be set on the VOMS server in /opt/glite/etc/voms/*/voms.conf:
  • On nodes that still use the classic grid-mapfile (LCG-CE, DPM, ...) check that it is updated via cron jobs like these:
Check that it contains the right value for the DN that had a problem.
  • Check that /opt/edg/etc/edg-mkgridmap.conf contains all the correct URLs for the VOs. For example:
 # Map VO members (sgm)
 group vomss:// dteamsgm

 # Map VO members (prd)
 group vomss:// dteamprd

 # Map VO members (root group)
 group vomss:// .dteam
  • Check that all accounts exist for each supported VO and that their shells are listed in /etc/shells.
  • Check if /etc/grid-security/gridmapdir on LCG-CE has these permissions:
 drwxrwx---    2 root     root            8192 Nov 29 15:08 gridmapdir
On the LCG-RB:
 drwxrwx---    2 root     edguser         8192 Nov 29 15:08 gridmapdir
On the gLite WMS:
 drwxrwx---    2 root     glite          20480 Dec 20 12:51 gridmapdir
On the DPM:
 drwxrwx---    2 root     dpmmgr         20480 Dec 14 10:15 gridmapdir
  • Check that /etc/grid-security/gridmapdir has an empty file for each pool account.
  • Check that /etc/profile.d/ and/or /etc/sysconfig/edg have:
  • The GridFTP daemon on the WMS needs LCMAPS_DB_FILE to point to a non-default configuration file:
 export LCMAPS_DB_FILE=/opt/glite/etc/lcmaps/lcmaps.db.gridftp
That needs to be in /etc/sysconfig/globus or /etc/sysconfig/globus-gridftp.
  • In /etc/grid-security/gridmapdir/ there is a hard link (with a strange name like %2fc%3dch%2fo%3dcern%2fou%3dgrid%2fcn%3dpiotr%20nyczyk%209654) to each pool account that is taken. Such a file has the same inode number as the corresponding pool account file (check with ls -li <filename>). An occupied pool account file has a link count of 2, whereas a free file has a link count of 1. The strange file name consists of a URL-encoding of the user proxy DN, possibly followed by a set of UNIX groups corresponding to VOMS attributes. If there is no free pool account file left for a particular group of users, another such user cannot be mapped and will be refused access. Usually this means that too few pool accounts were created. Stale pool accounts should be recycled by a cron job:
Check its logfile /var/log/lcg-expiregridmapdir.log e.g. as follows:
 # tail -999 /var/log/lcg-expiregridmapdir.log | grep ^VO | sort -u
 VO dteam: inuse / total = 70 / 99 = 0.71, thr = 0.8
  • See previous item: a file whose name contains the URL-encoded DN of a user proxy must be a hard link to a pool account file, otherwise the corresponding user proxy cannot be mapped to a pool account. (An incomplete cleanup could leave such dangling entries behind.) Also beware of stale mappings: if the hard link is to a file whose name starts with "foo", whereas the grid-mapfile specifies ".bar", the mapping typically fails (it may be auto-corrected on some services).
  • On a VOMS-aware service /etc/grid-security/grid-mapfile may need to contain entries mapping VOMS attributes to accounts:
 "/dteam/Role=lcgadmin/Capability=NULL" dteamsgm
 "/dteam/Role=lcgadmin" dteamsgm
 "/dteam/Role=production/Capability=NULL" dteamprd
 "/dteam/Role=production" dteamprd
 "/dteam/Role=NULL/Capability=NULL" .dteam
 "/dteam" .dteam
The /etc/grid-security/groupmapfile would have corresponding entries mapping VOMS attributes to groups:
 "/dteam/Role=lcgadmin/Capability=NULL" dteam
 "/dteam/Role=lcgadmin" dteam
 "/dteam/Role=production/Capability=NULL" dteam
 "/dteam/Role=production" dteam
 "/dteam/Role=NULL/Capability=NULL" dteam
 "/dteam" dteam