AlexsLemonade / AlexsLemonade/OpenScPCA-analysis

Bug report: Zellkonverter/Basilisk initialization in Docker images doesn't work with rstudio users

Open
#972 0 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
HTML
Stars
16
Forks
24
Avg merge
3d 5h
Merged PRs (30d)
4

Description

### Describe the bug

This is a followup issue to the problem noted in https://github.com/AlexsLemonade/OpenScPCA-analysis/discussions/968

In Docker images that use the `zellkonverter` package, we include a couple steps in the Dockerfile to pre-install the conda environment:

```
# Complete installation of zellkonverter conda env
ENV BASILISK_EXTERNAL_DIR /usr/local/renv/basilisk
RUN Rscript -e "proc <- basilisk::basiliskStart(env = zellkonverter::zellkonverterAnnDataEnv(), testload = 'anndata'); \
basilisk::basiliskStop(proc); \
basilisk.utils::cleanConda()"
```
e.g. https://github.com/AlexsLemonade/OpenScPCA-analysis/blob/82a2f659771960b4aee53a41165b1169c19f73df/analyses/cell-type-wilms-tumor-06/Dockerfile#L33C1-L37C32

This works well for the `root` user, which is used when running scripts within the Docker environment, as is done in Nextflow workflows. However, when using the docker image interactively, having the `BASILISK_EXTERNAL_DIR` environment variable
set causes us to run into a permissions issue with the lockfiles that are used by basilisk/conda.

### Steps to reproduce

1. Launch a rstudio-based Docker image that has a zellkonverter setup, such as `public.ecr.aws/openscpca/cell-type-wilms-tumor-06`
2. Login to RStudio with the `rstudio` user
3. Run `proc <- basilisk::basiliskStart(env = zellkonverter::zellkonverterAnnDataEnv(), testload = 'anndata')` in the R console

This will result in an error.

### Consequences of the bug

The code above, and generally using zellkonverter as the `rstudio` user, results in the following error.

```
Error in lock(plock, exclusive = FALSE) :
Cannot open lock file: Permission denied
```

This is at least in part because of the permissions settings of files in `/usr/local/renv/basilisk`, which are owned and initially only readable by the `root` user.

### Proposed solution

I initially tried changing the permissions of the `/usr/local/renv/basilisk` directory to make them read/writable by all users, but I am afraid that might not be sufficient, or we may need to adjust other permissions in that directory to make the permissions "sticky" so that all files in those subdirectories are accessible. We might also want to move the directory to `/usr/share` to reflect that usage.

Alternatively, we may want to find a way to more dynamically set `BASILISK_EXTERNAL_DIR` so that it is set for only the `root` user and not inherited by the `rstudio` user. That will mean that the `rstudio` user's first interaction with `zellkonverter` will require installation of the conda packages, but that seems preferable to a mysterious error.

In the mean time, there are two workarounds that can be used with the current setup:
- If working on the command line, launching the Docker image with `-e ROOT=TRUE` as an argument will set the `rstudio` user as an sudoer, so they can access the directory as needed with scripts.
- If working in the R console, adding `Sys.unsetenv("BASILISK_EXTERNAL_DIR")` before running `zellkonverter` functions will allow conda installation in the user's directory.

Contributor guide

Open the contributing guide

Research direction

Start with the Dockerfile setup shown in the issue and reproduce the basilisk::basiliskStart call as the rstudio user in public.ecr.aws/openscpca/cell-type-wilms-tumor-06. Investigate permissions under /usr/local/renv/basilisk and BASILISK_EXTERNAL_DIR behavior; done means zellkonverter initializes without the lock-file permission error for both intended users.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, r
Domain
devops, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.