I can't say anything about the 3dGroupInCorr problems right now -- it seems to be some network/security thing. Unless it is connecting to suma instead? However, unless you are superuser (root), you don't have permission to kill jobs belonging to other users.

OK, one 3dGroupInCorr thought -- try using the -NOshm option, which will avoid the default attempt to use shared memory instead of TCP/IP. If that doesn't work, then I suggest trying to use the plugout_drive program and see if it can connect successfully to AFNI to "drive" it via a TCP/IP connection, in a similar but simpler way than 3dGroupInCorr.

afni -yesplugouts
plugout_drive
Enter command: OPEN_WINDOW B

For the single-dataset InstaCorr problem, is it possible that you have a lot of large noise outside the brain? So that the automask algorithm is failing? (It looks for connected regions of high intensity stuff.) Try running 3dAutomask on the the same dataset and see what the resulting mask looks like overlaid on the input dataset. I've seen weird EPI data like that once or twice. Or since you are using errts, the scaling used in afni_proc.py could have created this as an artifact.

Just turn off masking in InstaCorr and mentally mask the dataset. Or read in the mask calculated by afni_proc.py (you DID use afni_proc.py, right?) instead of using the automask -- usually the afni_proc.py mask is in dataset mask_epi_anat -- and use that in InstaCorr.