0

I'm trying to deploy Atlantis on a Cloud Run Gen2 service with a GCS bucket mounted to it via gcsfuse.

Most seems to work fine, the atlantis server starts and can handle requests properly. Files are also written to the GCS bucket through gcsfuse.

But, when Atlantis tries to clone a git repository (as part of the: atlantis plan commmand) it returns the following error:

running git clone --branch f/gcsfuse-cloudrun --depth=1 --single-branch https://xxxxxxxx:<redacted>@github.com/xxxxxxxx/xxxxxxxx.git /app/atlantis/repos/xxxxxxxx/xxxxxxxx/29/default: Cloning into '/app/atlantis/repos/xxxxxxxx/xxxxxxxx/29/default'...
error: chmod on /app/atlantis/repos/xxxxxxxx/xxxxxxxx/29/default/.git/config.lock failed: Operation not permitted
fatal: could not set 'core.filemode' to 'false'
: exit status 128

I believe that I'm very close but I'm not too knowledgeable on Linux file system permissions.

My Dockerfile is as following:

FROM ghcr.io/runatlantis/atlantis:v0.21.1-pre.20221213-debian

USER root

# Install Python
ENV PYTHONUNBUFFERED=1
RUN apt-get update -y
RUN apt-get install -y python3 python3-pip

# Install system dependencies
RUN set -e; \
    apt-get update -y && apt-get install -y \
    tini \
    lsb-release; \
    gcsFuseRepo=gcsfuse-`lsb_release -c -s`; \
    echo "deb http://packages.cloud.google.com/apt $gcsFuseRepo main" | \
    tee /etc/apt/sources.list.d/gcsfuse.list; \
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | \
    apt-key add -; \
    apt-get update; \
    apt-get install -y gcsfuse \
    && apt-get clean

# Set fallback mount directory
ENV MNT_DIR /app/atlantis

# Create mount directory for service
RUN mkdir -p ${MNT_DIR}

RUN chown -R atlantis /app/atlantis/
RUN chmod -R 777 /app/atlantis/

WORKDIR  $MNT_DIR

# Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY gcsfuse_run.sh ./

# Make the script an executable
RUN chmod +x /app/gcsfuse_run.sh

ENTRYPOINT ["/app/gcsfuse_run.sh"]

The entrypoint script ^, is as following:

#!/usr/bin/env bash
set -eo pipefail

echo "Mounting GCS Fuse to $MNT_DIR"
gcsfuse -o allow_other -file-mode=777 -dir-mode=777 --implicit-dirs --debug_gcs --debug_fuse $BUCKET $MNT_DIR 
echo "Mounting completed."

# This is a atlantis provided docker script that comes from the base image
/usr/local/bin/docker-entrypoint.sh server

Help is highly appreciated!

Bruno Schaatsbergen
  • 326
  • 2
  • 14
  • Everything else aside, `file-mode=777` is an _incredibly_ bad idea; it's giving every user on your system, including untrusted accounts like `nobody` (which is often used for things like code handling unauthenticated incoming network connections) full read and write access to your content. – Charles Duffy Dec 25 '22 at 13:07
  • The other thing here is that the `chmod` that's falling is trying to change permissions _from_ that 777 to something else. It's possible it would still try even if the permissions were already correct, but also possible it wouldn't try, or that the fuse driver would describe such a noop operation as a success instead of throwing an error. – Charles Duffy Dec 25 '22 at 13:07
  • I'm aware of 777 being a terrible idea. A side from 777 I've first tried everything else (e.g. 644, etc) but all of those would throw various other errors that I still have to look into. I'm honestly just trying to get it to work first. – Bruno Schaatsbergen Dec 25 '22 at 13:11
  • You may need to rewrite the fuse driver so it stops calling chmod calls errors. – Charles Duffy Dec 25 '22 at 13:14
  • (or, better, so it checks the destination permissions and fails only if the destination and existing/global permissions differ) – Charles Duffy Dec 25 '22 at 13:19
  • 1
    (another thing to look into is whether there's global configuration for git you can apply to stop it from trying to set permissions on lockfiles altogether; though if it's written with the expectation that storage will be on POSIX-compliant operating systems, that very well may not be a feature that exists). – Charles Duffy Dec 25 '22 at 14:06
  • regarding the last point, global git config is always overwritten if local config is set (which is the case if a git clone is done, it sets core filemode to true). – Bruno Schaatsbergen Dec 25 '22 at 21:54
  • Git's support for environment-based config overrides is pretty extensive. I'd be astonished if you couldn't get an override in place one way or another. – Charles Duffy Dec 26 '22 at 02:55

2 Answers2

0

We simulated the exact steps, but didn't face the issue. Also we found the same type of issue on many places and for them below solutions worked :

  1. Run the server with sudo permission.
  2. Restart the system.
  3. git config --global --replace-all core.fileMode false
Tulsi Shah
  • 1
0

The chmod operation is not supported by gcsfuse. As such, the suggestion by @tulsi-shah (git config --global --replace-all core.fileMode false) would provide a work-around.

https://github.com/googlecloudplatform/gcsfuse/blob/master/docs/semantics.md#inodes

Mark van Holsteijn
  • 402
  • 4
  • 7