can't access lock file in shared mount

[yonisidi]

I am trying to use {pak} with a shared mount so users associated with a group can use same cache across sessions/instances similar to how {renv} can be configured.

since $USER is part of rstudio group there shouldn't be an issue for rw to files inside the pkgcache directory where {pak} is writing to

is there something I need to add to the pak call to resolve this? is there something similar to $RENV_CACHE_USER in pak that can manage who is the install user at runtime?

> pak::cache_list()
Error: 
! error in pak subprocess
Caused by error in `filelock::lock(lockfile, exclusive = exclusive, ...)`:
! Cannot open lock file: Permission denied
Type .Last.error to see the more details.

U1037187@pipeline-669380:~$ groups $USER
U1037187 : U1037187 root sudo rstudio

U1037187@pipeline-669380:~$ echo $R_PKG_CACHE_DIR
/cloud-home/egds/.cache

U1037187@pipeline-669380:~$ ls /cloud-home/egds/.cache/R/pkgcache -la
total 20
drwxrwxr-x 5 egds rstudio 6144 Sep  4 20:50 .
drwxrwxr-x 4 egds rstudio 6144 Sep  4 20:50 ..
drwxrwxr-x 2 egds rstudio 6144 Sep  4 20:50 _metadata
drwxrwxr-x 2 egds rstudio 6144 Sep  4 20:50 pkg
drwxrwxr-x 7 egds rstudio 6144 Sep  4 20:50 sysreqs

U1037187@pipeline-669380:~$ ls /cloud-home/egds/.cache/R -la
total 16
drwxrwxr-x 4 egds rstudio 6144 Sep  4 20:50 .
drwxrwxr-x 4 egds rstudio 6144 Sep  4 20:20 ..
drwxrwxr-x 5 egds rstudio 6144 Sep  4 20:50 pkgcache
drwxrwxr-x 3 egds rstudio 6144 Sep  4 15:28 renv

U1037187@pipeline-669380:~$ getfacl /cloud-home/egds/.cache/R/pkgcache
getfacl: Removing leading '/' from absolute path names
# file: cloud-home/egds/.cache/R/pkgcache
# owner: egds
# group: rstudio
user::rwx
group::rwx
other::r-x

[gaborcsardi]

I think you can set R_PKG_CACHE_DIR to point to another directory.

[yonisidi]

yes. I set it to that path because it is a shared mount across users

the default pak cache dir would be ~/.cache/R/pkgcache

since all users are part of rstudio group shouldn't pak be able to manage that?

[gaborcsardi]

Does that file system support locking? I suspect not. In any case, I am not sure what pak can do differently.

[yonisidi]

if I remove the cache subdirectories and reinit pak it uses $USER as the owner of the cache and works fine for that one $USER, but doesn't allow other users to use the cache. so the fs supports locking.

after running pak::cache_list()

U1037187@pipeline-669410:~$ ls /cloud-home/egds/.cache/R/pkgcache/ -la
total 16
drwxrwxr-x 4 U1037187 U1037187 6144 Sep  5 14:00 .
drwxrwxr-x 4 egds     rstudio  6144 Sep  5 14:00 ..
drwxrwxr-x 2 U1037187 U1037187 6144 Sep  5 14:00 _metadata
drwxrwxr-x 2 U1037187 U1037187 6144 Sep  5 14:00 pkg
U1037187@pipeline-669410:~$ 

after installing a package w pak

U1037187@pipeline-669410:~$ ls /cloud-home/egds/.cache/R/pkgcache/ -la
total 36
drwxrwxr-x  5 U1037187 U1037187 6144 Sep  5 14:02 .
drwxrwxr-x  4 egds     rstudio  6144 Sep  5 14:00 ..
-rw-rw-r--  1 U1037187 U1037187 4742 Sep  5 14:02 bioc-sysreqs.dcf.gz
-rw-rw-r--  1 U1037187 U1037187   69 Sep  5 14:02 bioc-sysreqs.dcf.gz.etag
drwxrwxr-x 11 U1037187 U1037187 6144 Sep  5 14:02 _metadata
-rw-------  1 U1037187 U1037187    0 Sep  5 14:02 _metadata.lock
drwxrwxr-x  2 U1037187 U1037187 6144 Sep  5 14:00 pkg
drwxrwxr-x  7 U1037187 U1037187 6144 Sep  5 14:02 sysreqs

_metadata.lock assumes a very strict permission