Cannot write to /var/solr as 8983:8983

[Firesphere]

I get this error when the Solr container is booted up.

Executing /opt/docker-solr/scripts/solr-precreate dev /solr-conf
Creating /var/solr/data
Cannot write to /var/solr as 8983:8983
drwxr-xr-x 4 1000 1000 4096 Jul 25 23:39 /var/solr

[rfay]

It sounds like you have the UID:GID mixed up with the ports. 8983:8983 would be the ports...

Are you just using ddev get mkalkbrenner/ddev-solr and using it as-is? Please put the full output in the OP, probably along with the .ddev/docker-compose.solr.yaml if you have changed it.

You also may have an old solr volume sitting around from another adventure and perhaps with different ownership. Make sure you delete any docker volumes that you find in docker volume ls | grep solr

[Firesphere]

I've tried using ddev get mkalkbrenner/ddev-solr, ddev get ddev/ddev-drupal9-solr and https://github.com/ddev/ddev-contrib/tree/master/docker-compose-services/solr-4 these instructions

The last option is because of a migration.

I already had a volume, but it has been empty or deleted. I purged (docker system prune -af --volumes) multiple times in between.

This issue occurs on both clean projects as well as existing projects. I haven't been able to pin down any reason yet. When saying "clean project" I mean a completely clean checkout of the existing code (no Solr in there), a brand new project, as well as a project without any code yet, a pure ddev config --project-type=php, to which I added the Solr add-on of mkalkbrenner with ddev get mkalkbrenner/ddev-solr.

All of the above options, give the same permission issue.

[Firesphere]

This same process, worked just fine a few months ago. I'm 99% sure it is not the update from 1.21 to 1.22 of DDEV that's the problem. As this issue seems to pop up in more places, most notably here https://github.com/docker-solr/docker-solr/issues/419

[rfay]

This has automated tests that ran successfully last night, https://github.com/mkalkbrenner/ddev-solr/actions/runs/5654474004

What OS are you on and what docker provider are you using?

[Firesphere]

MacOS Ventura, Darwin Ichthyocentaurs.hub 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:23 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6020 arm64 Colima --version colima version 0.5.5 ddev -v ddev version v1.22.0 docker --version Docker version 20.10.24, build 297e128

[rfay]

As requested earlier, please show the full output where you're seeing this error.

I just did the whole process without incident, macOS arm64, colima:

$ ddev get mkalkbrenner/ddev-solr
Installing mkalkbrenner/ddev-solr:0.2.1
Downloading https://api.github.com/repos/mkalkbrenner/ddev-solr/tarball/0.2.1
0.2.1_2804725416.tar.gz 34.79 KiB / ? [------------------------------------=----] 356.21% 0s

Installing project-level components:
👍 commands/solr/solr
👍 docker-compose.solr.yaml
👍 solr/security.json

Installed DDEV add-on mkalkbrenner/ddev-solr, use `ddev restart` to enable.
Please read instructions for this addon at the source repo at
https://github.com/mkalkbrenner/ddev-solr
Please file issues and create pull requests there to improve it.
Installed solr:0.2.1 from mkalkbrenner/ddev-solr
rfay@rfay-tag1-m1:~/workspace/d10$ ddev restart
Restarting project d10...
 Network ddev-d10_default  Created
 Volume "ddev-d10_solr"  Created
 Volume "ddev-d10_zoo"  Created
 Container ddev-d10-zoo  Created
 Container ddev-d10-db  Created
 Container ddev-d10-solr  Created
 Container ddev-d10-web  Created
 Container ddev-d10-db  Started
 Container ddev-d10-zoo  Started
 Container ddev-d10-solr  Started
 Container ddev-d10-web  Started
Starting mutagen sync process... This can take some time.
..Mutagen sync flush completed in 7s.
For details on sync status 'ddev mutagen st d10 -l'
 Container ddev-router  Created
 Container ddev-router  Started
Restarted d10
Your project can be reached at https://d10.ddev.site https://127.0.0.1:49351

As requested earlier, please show your full output so we know when exactly you get this error. And also as requested, please do it with a dummy project. For example, mkdir junk && cd junk && ddev config --auto

[Firesphere]

It's in the issue starter. That's all the output I'm getting from the Solr container.

DDEV itself responds with Failed to startproject: container(s) failed to become healthy before their configured timeout or in 120 seconds. This may be just a problem with the healthcheck and not a functional problem. (container 'solr' exited, please use 'ddev logs -s solr' to find out why it failed)

Which is not really helpful.

I understand you would like more details, but I can only say, there are none.

This is on a clean project, on a clean installation.

Starting project... 
 Container ddev-project-db  Running 
 Container ddev-project-web  Running 
 Container ddev-project-solr  Recreate 
 Container ddev-project-solr  Recreated 
 Container ddev-project-solr  Started 
 Container ddev-router  Running 
Failed to start project: container(s) failed to become healthy before their configured timeout or in 120 seconds. This may be just a problem with the healthcheck and not a functional problem. (container 'solr' exited, please use 'ddev logs -s solr' to find out why it failed) 

I believe this is a Solr issue, not a DDEV issue, which is why I raised this issue on this repository and not DDEV

[rfay]

I do see that the solr container is using a user with id 8983, which is really a strange thing to do.

$ ls -l /var/solr
total 12
drwxrwx--- 4 solr root 4096 Jul 26 03:37 data
-rw-rw---- 1 solr root 3497 Jul 26 01:32 log4j2.xml
drwxrwx--- 2 solr root 4096 Jul 26 03:37 logs
solr@f0022430d634:/opt/solr-8.11.2$ id
uid=8983(solr) gid=8983(solr) groups=8983(solr)

[rfay]

The image has in it

                "SOLR_UID=8983",
                "SOLR_GROUP=solr",
                "SOLR_GID=8983",

[rfay]

For some reason though your volume is mounted with UID 1000.

Why don't you try colima stop and try it with OrbStack and see if the behavior is any different? That also gets you a completely clean docker environment. It does no harm.

[Firesphere]

I'll give it a try. UID 1000 is the "first" user on MacOS though, so that's worth keeping in mind?

[rfay]

My bet is it will work with OrbStack and you'll end up recreating colima, making sure you have current everything (brew upgrade) and you have stored away your databases.

ddev snapshot --all
colima delete
colima start --cpu 4 --memory 6 --disk 100 --vm-type=qemu --mount-type=sshfs --dns=1.1.1.1

[rfay]

I confirm that it works without incident on Orbstack as well.

[rfay]

If it doesn't work when you try it in OrbStack let's do a live debugging session with screenshare over in Discord.

[Firesphere]

After a lot of trial-and-error, I solved the problem.

I added the following line to the solr-configupdate file chmod -R solr:solr /var/solr Inside the bash if.

Then, on a clean VM, I started a DDEV project with Solr I started the project Then loaded my config (the project needs to be started to do so) Restarted DDEV Re-loaded my config Restarted DDEV again, because of Solr not picking up changes unless I restart it (I could reload the core, but it's faster to restart, usually)

That works, for now. I'm still entirely unsure as to what or why it's all giving me problems, as it didn't use to be a problem before.

It's still weird, but at least it works.

[rfay]

That's a totally reasonable technique, perhaps should be the default, no idea how this happened only to you.

I think it would also be reasonable to run the solr container as a different user than uid 8983, which is very strange.

[mkalkbrenner]

Is there a concrete suggestion to change something?

[rfay]

I think this can be closed; I'm not sure what @Firesphere ran into here.

But it is really odd and confusing that the solr image uses UID 8983 by default, confusing everybody with ports. In a perfect world we'd use a reasonable UID (1000?) and actually run the container with that UID. DDEV does that, running the containers with the user's UID.

[Firesphere]

Is there a concrete suggestion to change something?

Not immediately. Very probably that this was a case of PEBKAC