no such table: main.gravity

[TungstenE2]

This is a: FILL ME IN

Just updated to Docker Tag [2024.07.0]

When I Update Gravity I've this error message:

[i] Building tree...
[✗] Unable to build gravity tree in /etc/pihole/gravity.db_temp
Error: in prepare, no such table: main.gravity
[✗] Unable to create database. Please contact support.

How to run pihole -r command on docker on Synology?

Details

Related Issues

• I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar

pi-hole/pi-hole#5006

How to reproduce the issue

Steps to reproduce the behavior:

Go to 'Tools'
Click on 'Update Gravity'
Click on 'Update'
Wait untill the end of process

1. Environment data

• Operating System: ENTER HERE
• Hardware:
• Kernel Architecture:
• Docker Install Info and version:
  • Software source:
  • Supplimentary Software:
• Hardware architecture:

2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here
3. any additional info to help reproduce

These common fixes didn't work for my issue

• I have tried removing/destroying my container, and re-creating a new container
• I have tried fresh volume data by backing up and moving/removing the old volume data
• I have tried running the stock docker run example(s) in the readme (removing any customizations I added)
• I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
• I have tried running without my volume data mounts to eliminate volumes as the cause

If the above debugging / fixes revealed any new information note it here.
Add any other debugging steps you've taken or theories on root cause that may help.

[rdwebdesign]

Please generate and upload a debug Token:

Using the command line (inside the container):

• use pihole -d command.
• when asked to upload the log, answer Y.
• copy only the token and paste here.

Using the web interface:

• click on Tools > Generate Debug Log menu.
• then mark the second checkbox to upload the log and click on the big button.
• when finished, copy only the token and paste here.

[TungstenE2]

https://tricorder.pi-hole.net/wRIfJkfv/

[rdwebdesign]

[✗] Unable to build gravity tree in /etc/pihole/gravity.db_temp

It seems to be an issue with permissions.

---

Some of your files are using different users and unexpected permissions.

Your files:

-r-xr-xr-x 1 1026 users 0 Dec  1  2020 /etc/pihole/custom.list

-rw-r--r-- 1 1026 users 65 Sep 10 13:52 /etc/pihole/local.list

-r-xr-xr-x 1 1026 users 241 Sep  1  2022 /etc/pihole/logrotate

Normal permissions:

-rw-r--r-- 1 root root 0 Sep 10 10:39 /etc/pihole/custom.list

-rw-r--r-- 1 root root 65 Sep 10 16:53 /etc/pihole/local.list

-rw-r--r-- 1 root root 289 Sep 10 10:39 /etc/pihole/logrotate

Did you manually change the permissions inside your container?
Also, please post your compose file (or docker run command) used to start your container.

[rdwebdesign]

Sorry... wrong button. The issue is still open.

[TungstenE2]

no manual changes to container. no issues in past. Just updated today using portainer and run update afterwards with the error

[TungstenE2]

does this help?

[rdwebdesign]

Apparently you are bind mounting a host directory (/volume1/docker/Pihole/pihole-configs) in your container and probably some permissions were changed in this directory, causing the issue.

The new tag (2024.07.0) doesn't have changes related to permissions.

What was the previous tag you were using? 2024.06.0?
What happens if you start your container using the previous image?

[TungstenE2]

last image was beginning of 2024, not sure if I still have it

[rdwebdesign]

You don't need the actual image. If you know the previous tag, docker will pull the image.

[TungstenE2]

I have downgraded to tag 2024.03.2 and problem is solved. So something happened between 2024.03.2 and latest....

[PromoFaux]

Is this 2024.03.2 container pointing at the same volumes as the one that was having issues after upgrade?

Looking through the release notes since then, there have been no docker-specific changes in subsequent tags, and I can't see anything that would cause this specific issue - not least of all because we've not had any similar reports...

If you incrementally upgrade from 2024.03.2 -> 2024.05.0 ->2024.06.0 -> 2024.07.0, at what point does the issue start happening?

[TungstenE2]

yes, pointing at same volume.

would need to check incremental updgrades

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[TungstenE2]

issue still open

I can confirm 2024.05.0 and 2024.06.0 working fine.

@PromoFaux so issue started with 2024.07.0

[PromoFaux]

Now that you are on 2024.06.0... did you try going to 2024.07.0? I really can't see any differences between the two tags that would cause the error message you pasted in the OP.

Very curious....

[TungstenE2]

yes, I did. Rolled back to 2024.06.0