java.nio.file.NoSuchFileException: /opt/sonarqube/temp/README.txt

[LazGit]

Hello,

I'm using sonarqube:alpine with docker. I always get an error during a restart :

2016.12.28 07:00:34 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
Exception in thread "main" java.lang.RuntimeException: Failed to reset file system
        at org.sonar.process.monitor.Monitor.resetFileSystem(Monitor.java:133)
        at org.sonar.process.monitor.Monitor.startProcesses(Monitor.java:113)
        at org.sonar.process.monitor.Monitor.start(Monitor.java:107)
        at org.sonar.application.App.start(App.java:73)
        at org.sonar.application.App.main(App.java:184)
Caused by: java.nio.file.NoSuchFileException: /opt/sonarqube/temp/README.txt

But the file '/opt/sonarqube/temp/README.txt' does not exist. Everything works fine if I create the file manually.
The problem occurs during a docker restart or sonarqube restart after installing plugins.

[kalidasya]

@LazGit you are a lifesaver, I could not figure out what is wrong with my docker container, creating the file is indeed a working workaround

[degree]

Actually nothing helps in my case. I tried creating file, deleting, moving directory, changing access rights, etc....

I just see

root@ap-sonarqube-01:/opt/sonarqube# ls -al temp
ls: cannot access temp/README.txt: No such file or directory
total 4
drwxrwxrwx 1 root root   42 Mar  3 10:21 .
drwxr-xr-x 1 root root   39 Mar  3 10:17 ..
?????????? ? ?    ?       ?            ? README.txt
-rw-r--r-- 1 root root 2560 Mar  3 10:21 sharedmemory

after restart of sonarqube. This also affects :lts version.

[Asdafers]

+1 any news on a possible solution?

[xift810]

1 Modify conf/wrapper.conf
wrapper.java.additional.2=-Djava.awt.headless=true
wrapper.java.additional.2=-Djava.awt.headless=true -Djava.io.tmpdir=/opt/sonarqube/temp

2 Mount temp folder
- /opt/mount1/sonarqube/tmp:/opt/sonarqube/temp

[ogradyjd]

I just hit this today. Running on Redhat 7.2, Docker version 17.05.0-ce, build 89658be, Sonar 6.4, running with a simple docker run command - nothing fancy.

@xift810 I'm not sure how to do what you've said - do you mean I have to modify the wrapper.conf in a Dockerfile that I write?

Devs: This makes it impossible to update Sonar when running in docker. It's been around for 7 months now. Anyone want to weigh in on this?

[Godin]

@ogradyjd This is an open-source project, and it’s maintained by volunteers. No need to say "it has been X months..." - pull-requests are welcomed from anyone who knows how to improve this.

[ogradyjd]

@Godin Fair enough. I'm probably not the right person to be looking for linux-docker file system problems, but I'll give it a go. So far, though, I've only found references that seem to indicate these are "ghost files" that have no inode number, or some such like that. I think the below discussion is close, but since I'm new to docker, I'm not sure how the sonar-docker image is creating a bad or damaged container filesystem every time.

I'll look into it more, but I'm time-boxed on this. If anyone has any more info or can contribute knowledge from the docker side of things, maybe we can triangulate on what the source of the problem is. I'm guessing not everyone that uses this image has this problem?

https://unix.stackexchange.com/questions/148486/delete-ghost-files-with-special-characters

[Godin]

@ogradyjd and others - what are the exact steps to reproduce this?

I'm asking because can't reproduce:

$ docker version
Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:31:53 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:51:55 2017
 OS/Arch:      linux/amd64
 Experimental: true

$ docker images
sonarqube           5.6.6-alpine        e9165a354539        2 weeks ago         248MB

$ docker run -d --name sonarqube -p 9000:9000 sonarqube:5.6.6-alpine

$ docker restart sonarqube

$ docker stop sonarqube

$ docker start sonarqube

$ docker logs sonarqube | grep -E "Web server is (stopped|started)"
2017.07.13 10:29:33 INFO  web[o.s.s.a.TomcatAccessLog] Web server is started
2017.07.13 10:31:14 INFO  web[o.s.s.a.TomcatAccessLog] Web server is stopped
2017.07.13 10:31:46 INFO  web[o.s.s.a.TomcatAccessLog] Web server is started
2017.07.13 10:32:12 INFO  web[o.s.s.a.TomcatAccessLog] Web server is stopped
2017.07.13 10:32:52 INFO  web[o.s.s.a.TomcatAccessLog] Web server is started

After such restarts there is no exceptions in log:

$ docker logs sonarqube | grep "Exception" | wc -l
0

[v-chyzhevskyi]

@Godin, for reproducing this exception you need to use sonar of 6.* version, not 5.*
I reproduced this error on sonar 6.5.

[Godin]

@v-chyzhevskyi

$ docker run -d --name sonarqube -p 9000:9000 sonarqube:6.5-alpine

$ docker restart sonarqube

$ docker stop sonarqube

$ docker start sonarqube

$ docker logs sonarqube  | grep -E "\[web\] is"
2017.09.09 10:23:01 INFO  app[][o.s.a.SchedulerImpl] Process[web] is up
2017.09.09 10:23:15 INFO  app[][o.s.a.SchedulerImpl] Process [web] is stopped
2017.09.09 10:23:34 INFO  app[][o.s.a.SchedulerImpl] Process[web] is up
2017.09.09 10:23:57 INFO  app[][o.s.a.SchedulerImpl] Process [web] is stopped
2017.09.09 10:24:28 INFO  app[][o.s.a.SchedulerImpl] Process[web] is up

$ docker logs sonarqube | grep "Exception" | wc -l 
0

[nthienan]

I have faced the same issue.

Sonar version: Version 6.5 (build 27846)

$ docker version
Client:
 Version:      17.06.2-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 19:59:06 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.2-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 20:00:25 2017
 OS/Arch:      linux/amd64
 Experimental: false

Here is errors:

2017.09.28 09:32:17 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
Exception in thread "main" java.nio.file.NoSuchFileException: /opt/sonarqube/temp/README.txt
        at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
        at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
        at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
        at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
        at java.nio.file.Files.readAttributes(Files.java:1737)
        at java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:225)
        at java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
        at java.nio.file.FileTreeWalker.next(FileTreeWalker.java:372)
        at java.nio.file.Files.walkFileTree(Files.java:2706)
        at org.sonar.application.AppFileSystem.createOrCleanTempDirectory(AppFileSystem.java:96)
        at org.sonar.application.AppFileSystem.reset(AppFileSystem.java:62)
        at org.sonar.application.App.start(App.java:53)
        at org.sonar.application.App.main(App.java:75)

[nthienan]

I use Sonar version 6.4 (build 25310) and do not face this issue.

[Godin]

@thienan93

$ docker version
Client:
 Version:      17.06.2-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 19:59:06 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.2-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 20:00:25 2017
 OS/Arch:      linux/amd64
 Experimental: false

$ docker images
sonarqube           6.5                 7b4cbfc2b51a        2 weeks ago         916MB

$ docker run -d --name sonarqube -p 9000:9000 sonarqube:6.5

$ docker restart sonarqube

$ docker stop sonarqube

$ docker start sonarqube

$ docker logs sonarqube  | grep -E "\[web\] is"
2017.09.28 10:15:22 INFO  app[][o.s.a.SchedulerImpl] Process[web] is up
2017.09.28 10:15:39 INFO  app[][o.s.a.SchedulerImpl] Process [web] is stopped
2017.09.28 10:16:07 INFO  app[][o.s.a.SchedulerImpl] Process[web] is up
2017.09.28 10:16:32 INFO  app[][o.s.a.SchedulerImpl] Process [web] is stopped
2017.09.28 10:17:03 INFO  app[][o.s.a.SchedulerImpl] Process[web] is up

$ docker logs sonarqube | grep "Exception" | wc -l 
0

[nthienan]

I used docker-compose and volumes:

version: '2'
services:
  sonarqube:
    restart: always
    image: sonarqube
    ports:
      - "9000:9000"
    networks:
      - sonarnet
    environment:
      - SONARQUBE_JDBC_URL=jdbc:postgresql://postgre:5432/sonar
    volumes:
      - /opt/sonarqube/conf:/opt/sonarqube/conf
      - /opt/sonarqube/data:/opt/sonarqube/data
      - /opt/sonarqube/extensions:/opt/sonarqube/extensions
      - /opt/sonarqube/bundled-plugins:/opt/sonarqube/lib/bundled-plugins
      - /opt/sonarqube/temp:/opt/sonarqube/temp
    command: -Dhttps.proxyHost=192.168.1.100 -Dhttps.proxyPort=8080 -Dhttp.proxyHost=192.168.1.100 -Dhttp.proxyPort=8080
  postgre:
    restart: always
    image: postgres
    networks:
      - sonarnet
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
    volumes:
      - /opt/sonarqube/postgresql:/var/lib/postgresql
      - /opt/sonarqube/postgresql/data:/var/lib/postgresql/data
networks:
  sonarnet:
    driver: bridge

[Godin]

@thienan93 docker-composewith volumes also works fine:

$ mkdir -p /tmp/sonarqube

$ cd /tmp/sonarqube

$ cat <<END > docker-compose.yml
version: '2'
services:
  sonarqube:
    image: sonarqube
    ports:
      - "9000:9000"
    networks:
      - sonarnet
    environment:
      - SONARQUBE_JDBC_URL=jdbc:postgresql://postgres:5432/sonar
    volumes:
      - /tmp/sonarqube/conf:/opt/sonarqube/conf
      - /tmp/sonarqube/data:/opt/sonarqube/data
      - /tmp/sonarqube/extensions:/opt/sonarqube/extensions
      - /tmp/sonarqube/bundled-plugins:/opt/sonarqube/lib/bundled-plugins
      - /tmp/sonarqube/temp:/opt/sonarqube/temp
  postgres:
    image: postgres
    networks:
      - sonarnet
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
    volumes:
      - /tmp/sonarqube/postgresql:/var/lib/postgresql
      - /tmp/sonarqube/postgresql/data:/var/lib/postgresql/data
networks:
  sonarnet:
    driver: bridge
END

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
postgres            latest              1227c4263c8c        10 days ago         265MB
sonarqube           latest              7b4cbfc2b51a        2 weeks ago         916MB

$ docker-compose create postgres

$ docker-compose start postgres

$ docker-compose create sonarqube

$ docker-compose start sonarqube

$ docker-compose restart sonarqube

$ docker logs sonarqube_sonarqube_1  | grep -E "\[web\] is"
2017.09.29 10:06:35 INFO  app[][o.s.a.SchedulerImpl] Process[web] is up
2017.09.29 10:07:14 INFO  app[][o.s.a.SchedulerImpl] Process [web] is stopped
2017.09.29 10:07:33 INFO  app[][o.s.a.SchedulerImpl] Process[web] is up

$ docker logs sonarqube_sonarqube_1 | grep "Exception" | wc -l
0

And let's clarify following moment - statement that there is problem with image/Dockerfile for 6.5 and no such problem with 6.4 is extremely strange, because the only difference between them is c6aa0bb So either there is problem with both, or with none of them, or problem is not at all in Dockerfile. And in the last case there is nothing to fix in images/Dockerfiles provided by this repository. And this repository/issue-tracker is not the right place to get generic support about proper usage of docker, docker-compose, volumes, your infrastructure around them, etc etc. Thank you for your understanding.

[nthienan]

@Godin,
I do not go to here to ask about usage of docker or docker-compose. I just want to report an issue that I've faced and try to give more related information.

[ginsburgnm]

@Godin
This is actually an issue with security context, and still present today. I ran into this with the latest release.

Here's what's happening. When you run the docker image locally, it doesn't really matter; you can have a USER sonarqube run things. However, when you are in an enterprise environment, what is likely the case is that your kubernetes/openshift/whatever environment will not allow you to specify a user to run as; this is a security policy. If the policy on the kube cluster is set to allow anyuid and individual "forgets" to set USER in their Dockerfile then that individual is root in the container. And bad things happen when you run a container as root.

When you can't set USER the kube cluster just gives you a misc user, this user does not have access to files owned by sonarqube

But let's keep going, why do you need USER sonarqube? well, taking it out, I saw that elasticsearch is embedded in there, and you can't run that as root; well great. likely that means additional work needs to be done to appropriately containerize this application, but let's skip that.

How would one run this application in an (appropriately) locked down kube cluster?

# Slightly modified your Dockerfil
FROM openjdk:11-jre-slim

RUN apt-get update \
    && apt-get install -y curl gnupg2 unzip \
    && rm -rf /var/lib/apt/lists/*

ENV SONAR_VERSION=7.9.2 \
    SONARQUBE_HOME=/opt/sonarqube \
    SONARQUBE_JDBC_USERNAME=sonar \
    SONARQUBE_JDBC_PASSWORD=sonar \
    SONARQUBE_JDBC_URL=""

# Http port
EXPOSE 9000

RUN for server in $(shuf -e ha.pool.sks-keyservers.net \
                            hkp://p80.pool.sks-keyservers.net:80 \
                            keyserver.ubuntu.com \
                            hkp://keyserver.ubuntu.com:80 \
                            pgp.mit.edu) ; do \
        gpg --batch --keyserver "$server" --recv-keys F1182E81C792928921DBCAB4CFCA4A29D26468DE && break || : ; \
    done

RUN set -x \
    && cd /opt \
    && curl -o sonarqube.zip -fSL https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-$SONAR_VERSION.zip \
    && curl -o sonarqube.zip.asc -fSL https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-$SONAR_VERSION.zip.asc \
    && gpg --batch --verify sonarqube.zip.asc sonarqube.zip \
    && unzip -q sonarqube.zip \
    && mv sonarqube-$SONAR_VERSION sonarqube \
    && rm sonarqube.zip* \
    && rm -rf $SONARQUBE_HOME/bin/* \
    && touch $SONARQUBE_HOME/logs/es.log

COPY run.sh $SONARQUBE_HOME/bin/

# well, since we can't choose which user we are to run as
# let's allow literally anyone to read/write/execute anything in /opt/sonarqube
# this is disgusting, and also increases build times by a lot
RUN chmod -R 777 "$SONARQUBE_HOME" 

VOLUME "$SONARQUBE_HOME/data"

WORKDIR $SONARQUBE_HOME
# elasticsearch will still gripe if you don't specify a user when you're testing locally 
# so you need this for the environment's that will let you run as root
RUN groupadd -r sonarqube && useradd -r -g sonarqube sonarqube
USER sonarqube
ENTRYPOINT ["/opt/sonarqube/bin/run.sh"]

The reason I'm not opening a PR here, is because this is still a bad solution. It does work in more cases than your current Dockerfile, but the fact that I have to do this suggests there is a greater issue at hand and this is just a disgusting workaround; merging this in will likely make people ignore the actual issue.

Hopefully someone finds this helpful.