4 / 9
Sep 2024

I just updated our egw VM using apt. We are on the egroupware/egroupware:23.1 branch. The apt upgrade appears to have pulled in 23.1.20240930-2. After the upgrade, access to the web UI nets this long message in the browser:

Failed opening required ‘/usr/share/egroupware/vendor/egroupware/adodb-php/adodb-time.inc.php’ (include_path=’/usr/share/egroupware/vendor/pear/xml_util:/usr/share/egroupware/vendor/pear/structures_graph:/usr/share/egroupware/vendor/pear/console_getopt:/usr/share/egroupware/vendor/pear/archive_tar:/usr/share/egroupware/vendor/pear/pear_exception:/usr/share/egroupware/vendor/pear/auth_sasl:/usr/share/egroupware/vendor/pear/log:/usr/share/egroupware/vendor/pear/xml_feed_parser:/usr/share/egroupware/vendor/pear/pear:.:/usr/share/php’) (0)

I tried ‘apt install egroupware-docker --reinstall’, then a reboot. Same result.

I ran these commands, which I think ultimately did the same thing, and also made no difference.

cd /etc/egroupware-docker
docker-compose pull
docker-compose up -d

To get our calendars working I changed docker to the previous released version 23.1.20240905 by changing this line in /etc/egroupware-docker/docker-compose.override.yml:

image: egroupware/egroupware:23.1

to:

image: egroupware/egroupware:23.1.20240905

After the docker-compose pull and up commands, the system operated normally.

I’m happy to answer any questions. If you need information from me, please assume I know nothing about docker when you pose your request.

Thanks,
Steve

  • created

    Sep '24
  • last reply

    Oct '24
  • 8

    replies

  • 395

    views

  • 3

    users

  • 4

    likes

  • 2

    links

I should have mentioned: on Debian 12 on x86-64, all packages up to date.

Interesting, we use only local DB for user management.
On system works with 23.1.20240930 and the other not, going back to 23.1.20240905 solved the issue as well.

You a right and that solved as well the mystery why it works on my other setup.

Do not work for me:

docker exec egroupware rm "/var/lib/php/sessions/sess_*"
rm: cannot remove '/var/lib/php/sessions/sess_*': No such file or directory

And yes, there are sessions:

/var/lib/php/sessions# ls -l | wc -l 
14

But simply…

docker exec -it egroupware /bin/bash
cd /var/lib/php/sessions/
rm sess_*

…works :slight_smile:

The solution works here as well. Thank you for the quick response.

Regarding the command to remove the session files in the container, this also works. ‘docker exec’ probably just calls exec() so there is no shell to expand the globbed path and it is treated literally by ‘rm’.

docker exec egroupware bash -c 'rm /var/lib/php/sessions/sess_*'