"attempt to write a readonly database" although 777

I wanted to migrate my grafana database to a new host (Ubuntu 19.10)
Setup works perfectly, but when I copy my old grafana.db to the new server I get this error when logging in;

t=2020-04-14T08:51:47+0000 lvl=info msg="Successful Login" logger=http.server User=user@myDomain.com
t=2020-04-14T08:51:47+0000 lvl=eror msg="Request error" logger=context userId=0 orgId=0 uname= error="runtime error: invalid memory address or nil pointer dereference" stack="/usr/local/go/src/runtime/panic.go:199 (0x44d65b)\n/u>
t=2020-04-14T08:51:47+0000 lvl=eror msg="Request Completed" logger=context userId=0 orgId=0 uname= method=POST path=/login status=500 remote_addr=192.168.178.37 time_ms=18 size=1717 referer=http://192.168.178.91:3000/login

For testing, I set the permissions to 777 but the error persists:

![pve_-_Proxmox_Virtual_Environment-3|565x500](upload://oT

8IG92uwSqEL6abjqAbNaSa2tq.png)

I do not understand, why this persists, even with 777 permissions

In theory this is not needed, but I had to change the permissions of everyone to write (yes, all)

chmod -R a+w /var/lib/grafana

This sounds to me more like an ownership problem than a permissions problem.

You’ve said you’ve tried changing the permissions to 777 on everything (which
I do NOT ever recommend as even a medium-term solution - try it by all means
as a debugging tool to see if it makes the error go away, but then find the
proper solution and use that instead).

However, what are the ownerships on your files in and under /var/lib/grafana?

Is it possible that you’ve copied them (you don’t say how this was done) in
such a way that either:

a) the old ownership was preserved and that user or ID no longer exists on the
new machine

b) the files got copied as root and now have an ownership which Grafana can’t
work with

c) Ubuntu 19.10 runs Grafana differently from whatever it was you upgraded from

Antony.

It is probably an ownership problem. In my case, despite I was specifying the proper USER id and GROUP id to the docker image and the volume mounted into it had the proper ownership wit the IDs I specified to the docker image. However it didn’t worked until:

  • I used the group id and user id the container uses instead the ones I was specifying to it
  • I added write permissions to all recursively on the mounted volume