Accessing Nextcloud from HPC
There are two ways to reach your Nextcloud storage from the HPC side: mounting it on Elja only, for occasional, low-volume transfers, or mounting it directly on the Slurm cluster, for jobs that need to read or write it while running. Going the other direction — reaching HPC/Elja storage from Nextcloud — is covered in Accessing HPC Storage from Nextcloud.
Mounting Nextcloud storage as a volume on Elja only
Elja's login node is just a Linux machine, so you can mount your Nextcloud storage there the same way as on any Linux machine — see the Linux section of Mounting Nextcloud as a Local Drive for the walkthrough.
This is primarily useful for occasional, low-volume data transfer between your workspace on Elja and Nextcloud. This mounted volume is not accessible from Slurm worker nodes — if you run batch jobs via Slurm, write results to your home directory or scratch space first, then copy them to the Nextcloud mount afterward.
For live database files or other data that needs proper file-locking support, use a direct NetApp mount instead of WebDAV — see Live Database Files Get Corrupted by Sync.
Mounting Nextcloud storage directly on the Slurm cluster
Most Slurm jobs are well served by writing results to scratch space or your Elja home directory and syncing to Nextcloud afterward (see above) — that's simpler to set up and doesn't require group membership. This direct-mount approach is only for jobs that need to read or write Nextcloud storage while running, not just before or after.
If your batch jobs do need that, your Nextcloud storage has to be mounted directly on the Slurm cluster nodes rather than just on Elja's login node. This is a three-part setup: IREI first grants you membership in a restricted group (WebDAV mounts on shared compute infrastructure have to be controlled carefully), then you configure your own credentials, and finally you add mount/unmount steps to each batch script that needs the storage.
1. Request access
Mounting Nextcloud storage on the HPC system is gated behind the [GROUP_NAME] group. To request access to the group:
- Contact the HPC administrators at irei@hi.is
Include your HPC username and a brief justification for needing direct Nextcloud access from the cluster.
Once approved, you'll be added to the group, and you should log out and back in (or run newgrp davfs2) for the membership to take effect.
2. Store your credentials
Once you're in the group, set up your WebDAV credentials in ~/.davfs2/secrets (same format as the standalone Linux instructions):
mkdir -p ~/.davfs2
cat <<EOF > ~/.davfs2/secrets
https://ireigogn.hi.is/remote.php/dav/files/<hpcusername>/ <hpcusername> <app-password>
EOF
chmod 600 ~/.davfs2/secrets
Use your link login name (HPC username) and the app password generated in Nextcloud, not your regular account password.
3. Mount and unmount with cloud_connect2
The cluster provides a wrapper script, cloud_connect2, that handles the davfs2 mount/unmount for you using the credentials in ~/.davfs2/secrets. Your Nextcloud storage is mounted at:
/hpchome/share/mnt/<hpcusername>
To mount:
cloud_connect2
To unmount:
cloud_connect2 --unmount
Because HPC nodes are shared, you must not leave the mount open outside of active use. If your job reads from or writes to your Nextcloud storage, mount it at the start of the job and unmount it at the end, inside the same batch script:
#!/bin/bash
#SBATCH --job-name=my-job
#SBATCH ...
cloud_connect2
# your calculations, reading/writing under /hpchome/share/mnt/<hpcusername>
./my_program --input /hpchome/share/mnt/<hpcusername>/data --output ./results
cloud_connect2 --unmount
Leaving the mount active after your job finishes (or across multiple concurrent jobs) can cause conflicts or stale mounts on shared nodes, so always unmount as one of the last steps in the script, even if the job fails partway through — consider wrapping the calculation step with a trap to guarantee cloud_connect2 --unmount runs on exit.