Permission error in home directory. How to redirect .config to another folder on HPC?

[eskavvas (Erol Kavvas)]

Hi,

I'm trying to run qiime2 on a HPC cluster but I'm running into a permission error in my home directory. I contacted the administrator and he recommended that I redirect the location of .config to the /share folder in which I'm executing the slurm command (/share/taglab/Erol/). How can I do this?

This is the slurm script that I'm running in /share/taglab/Erol/ (not /home/eskavvas/)

#!/bin/bash

#SBATCH --job-name=denoise
#SBATCH --nodes=1
#SBATCH --ntasks=64
#SBATCH --time=12:00:00
#SBATCH --mem=50G
#SBATCH --partition=production
#SBATCH --output=stdout_%j.out
#SBATCH --error=stderr_%j.err
#SBATCH --array=1-15 # this specifies the number of jobs to run in array.. corresponds to the files in my directory

module load anaconda3/4.8.3
module load qiime2/2020.8
source activate qiime2-2020.8

echo "My SLURM_ARRAY_TASK_ID: " $SLURM_ARRAY_TASK_ID
name=`sed "${SLURM_ARRAY_TASK_ID}q;d" samples.txt`

echo $name

qiime dada2 denoise-single \
--i-demultiplexed-seqs ./demux_seqs_fd_$name.qza \
--p-trunc-len 150 \
--p-n-threads 0 \
--o-table ./dada2_table_fd_$name.qza \
--o-representative-sequences ./dada2_rep_set_fd_$name.qza \
--o-denoising-stats ./dada2_stats_fd_$name.qza

echo denoising done!

This is the resulting error.

Traceback (most recent call last):
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/bin/qiime", line 11, in
sys.exit(qiime())
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/site-packages/click/core.py", line 829, in call
return self.main(*args, **kwargs)
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/site-packages/click/core.py", line 1254, in invoke
cmd_name, cmd, args = self.resolve_command(ctx, args)
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/site-packages/click/core.py", line 1297, in resolve_command
cmd = self.get_command(ctx, cmd_name)
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/site-packages/q2cli/commands.py", line 100, in get_command
plugin = self._plugin_lookup[name]
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/site-packages/q2cli/commands.py", line 76, in _plugin_lookup
import q2cli.core.cache
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/site-packages/q2cli/core/cache.py", line 406, in
CACHE = DeploymentCache()
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/site-packages/q2cli/core/cache.py", line 58, in init
self._cache_dir = self._get_cache_dir()
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/site-packages/q2cli/core/cache.py", line 85, in _get_cache_dir
os.makedirs(cache_dir, exist_ok=True)
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/os.py", line 210, in makedirs
makedirs(head, mode, exist_ok)
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/os.py", line 210, in makedirs
makedirs(head, mode, exist_ok)
File "/software/qiime2/2020.8/lssc0-linux/miniconda3/envs/qiime2-2020.8/lib/python3.6/os.py", line 220, in makedirs
mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/home/eskavvas/.config'

I was looking on the forum it seems like a similar issue comes up with using dockers, but I'm not sure how to fix it in this case.

I appreciate any help, thanks!
Erol

[thermokarst]

Hi @eskavvas!

This error is coming from q2cli, it is attempting to populate a tool cache. The rules for that population are as follows:

1. attempt to create the cache inside the conda environment. If the current user doesn’t have permission to do that, then:
2. attempt to create the cache inside the current user’s home directory, as described here: API — Click Documentation (7.x)

Unfortunately we don’t have a mechanism for you to escape or control this behavior, since it is typically considered a reasonable expectation to assume that a user has permission to write to their own homedir (this is basically the point of a home directory).

I’m surprised to see that your user account doesn’t have permission to create this directory inside your own home directory - perhaps you can ask for clarification from your sysadmin about this? This implies to me that there might be an issue with this job’s submission on your cluster, like maybe your user account information is being overridden somehow on submission? I’m not sure, and there are probably a handful of additional details to check into on your end there, but please keep us posted!

EDIT:

Just to confirm, are you able to create this directory manually? Maybe if you do that and re-run you’ll be set?

mkdir /home/eskavvas/.config

[eskavvas (Erol Kavvas)]

Hi Matthew,

Thanks for the very quick and thoughtful response!

It looks like the config file was already made, so it seems like it was able to write to my home directory at some point. This is what the administrator told me to do if redirecting the config from home is not an option. I believe the problem is due to an expired access token.

It could be that your access token for the fileserver has timed out.
You can check with the 'tokens' command. When you log in to the
cluster, you are automatically granted an access token, but this token
has a finite life and once it expires you will need to re-authenticate
in order to access the fileserver again.

For this reason, we recommend running jobs out of your lab share instead
of your home directory, so the first thing I would try would be to
redirect the config file shown there.

If you do need to access your home from your job, make sure you have a
valid access token before you submit your jobs. You can request a new
token if needed with the following commands:

kinit
aklog

And also add the "aklog" command to the top of your job script.

If you want to request a longer access token than the default, you can
use the -l flag to kinit to specifiy a different lifetime. For a 2-day
token, use:

kinit -l 2d
aklog

I've now submitted the job with the extended access token, so hopefully it should work now. I appreciate the help!

Best,
Erol

[thermokarst]

Ah perfect, that access token seems to explain it! FWIW, you shouldn’t need to create long-running access token for this, the cache is only populated once per QIIME 2 release activation. So when you install a new version of QIIME 2, it’ll recache the first time you activate the env, but then never again until you install an even newer version.