2

I'm trying to deploy Nexus3 as a Kubernetes pod in IBM Cloud service. I am getting this error, probably because the PVC is mounted as read only for that user. I have had this problem other times in Postgres for example but I can't recall how to solve it:

mkdir: cannot create directory '../sonatype-work/nexus3/log': Permission denied
mkdir: cannot create directory '../sonatype-work/nexus3/tmp': Permission denied
Java HotSpot(TM) 64-Bit Server VM warning: Cannot open file ../sonatype-work/nexus3/log/jvm.log due to No such file or directory

Warning:  Cannot open log file: ../sonatype-work/nexus3/log/jvm.log
Warning:  Forcing option -XX:LogFile=/tmp/jvm.log
Unable to update instance pid: Unable to create directory /nexus-data/instances
/nexus-data/log/karaf.log (No such file or directory)
Unable to update instance pid: Unable to create directory /nexus-data/instances

These are the PVC and POD yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nexus-pvc
  annotations:
    volume.beta.kubernetes.io/storage-class: "ibmc-file-retain-bronze"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

apiVersion: v1
kind: Pod
metadata:
  name: nexus
  labels:
    name: nexus
spec:
  containers:
    - name: nexus
      image: sonatype/nexus3
      ports:
        - containerPort: 8081
      volumeMounts:
        - name: nexus-data
          mountPath: /nexus-data
        - name: tz-config
          mountPath: /etc/localtime
  volumes:
  - name: nexus-data
    persistentVolumeClaim:
      claimName: nexus-pvc
  - name: tz-config
    hostPath:
      path: /usr/share/zoneinfo/Europe/Madrid
Jeff Sloyer
  • 4,899
  • 1
  • 24
  • 48
icordoba
  • 1,834
  • 2
  • 33
  • 60

2 Answers2

1

The nexus3 Dockerfile is structured such that it runs as a non-root user. However, the NFS file storage requires root user to access and write to it. There are a couple of ways to fix this. One, you can restructure your Dockerfile to temporarily add the non-root user to root and change the volume mount permissions. Here are instructions for that: https://console.bluemix.net/docs/containers/cs_storage.html#nonroot

Another option is to run an initContainer (https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) that changes the mount path ownership before the main container runs. The initContainer would look something like this:

initContainers:
      - name: permissionsfix
        image: ubuntu:latest
        command: ["/bin/sh", "-c"]
        args:
          - >
            chown 1000:1000 /mount;
        volumeMounts:
        - name: volume
          mountPath: /mount
Andrew Lohr
  • 5,380
  • 1
  • 26
  • 38
bhpratt
  • 374
  • 1
  • 6
  • Thanks for your answers. Quick question... how come I don't have this problem for example when I deploy Postgres using the same PVC volumes? Postgres does not write the files as root... – icordoba Mar 01 '18 at 21:04
  • The difference is in the structure of the Dockerfile / entrypoint scripts. With postgres the container is running with root privilege and the `/docker-entrypoint.sh` is launching `postgres` as non-root user process. So in this case entry point script is running as `root` user. The entry-point can execute `chown -R postgres "$PGDATA"` as it has root privilege. For Nexus, the container is running as non-root due to `USER nexus`. The NFS volume is owned by root on the host but the Dockerfile is attempting to have the mount path be owned by the non-root user. – bhpratt Mar 02 '18 at 16:38
0

File storage has these permission issues. Instead of using file based volumes, use block based volumes.

Install the block storage plugin and update your resources to use the newly available storage classes. An example of usage:

storage:
  type: persistent-claim
  size: 100Gi
  deleteClaim: false
  class: "ibmc-block-retain-bronze"