Should work, apart from permissions as user IDs may be different between containers, but can be fixed with chown.
Let me know what manual fixes you have to make I will try to fix it in platform.
Ok, done. Photoprism is installed but when I try to access it in the browser I get an nginx 502 Bad Gateway error.
The corresponding log entries look like this:
Feb 04 18:07:11 macmini photoprism.web[20034]: time="2025-02-04T18:07:11Z" level=error msg="Error 1049 (42000): Unknown database 'photoprism'"
Feb 04 18:07:12 macmini systemd[1]: snap.photoprism.web.service: Succeeded.
Feb 04 18:07:12 macmini systemd[1]: snap.photoprism.web.service: Consumed 5.908s CPU time.
Feb 04 18:07:12 macmini systemd[1]: snap.photoprism.web.service: Service RestartSec=100ms expired, scheduling restart.
Feb 04 18:07:12 macmini systemd[1]: snap.photoprism.web.service: Scheduled restart job, restart counter is at 12.
Feb 04 18:07:12 macmini systemd[1]: Stopped Service for snap application photoprism.web.
Feb 04 18:07:12 macmini systemd[1]: snap.photoprism.web.service: Consumed 5.908s CPU time.
Feb 04 18:07:12 macmini systemd[1]: Started Service for snap application photoprism.web.
Feb 04 18:07:18 macmini photoprism.web[20239]: time="2025-02-04T18:07:18Z" level=info msg="config: waiting for the database to become available"
Additionally I frequently have these messages in the log:
Feb 04 18:14:15 macmini systemd[1]: dev-sda1.device: Job dev-sda1.device/start timed out.
Feb 04 18:14:15 macmini systemd[1]: Timed out waiting for device /dev/sda1.
Feb 04 18:14:15 macmini systemd[1]: Dependency failed for /dev/sda1.
Feb 04 18:14:15 macmini systemd[1]: dev-sda1.swap: Job dev-sda1.swap/start failed with result 'dependency'.
Feb 04 18:14:15 macmini systemd[1]: dev-sda1.device: Job dev-sda1.device/start failed with result 'timeout'.
It may take some time to start, create db …
What does it say after 5/10 mins?
No change.
Feb 05 19:38:10 macmini photoprism.web[21333]: time="2025-02-05T19:38:10Z" level=error msg="Error 1049 (42000): Unknown database 'photoprism'"
Feb 05 19:38:10 macmini systemd[1]: snap.photoprism.web.service: Succeeded.
Feb 05 19:38:10 macmini systemd[1]: snap.photoprism.web.service: Consumed 6.044s CPU time.
Feb 05 19:38:10 macmini systemd[1]: snap.photoprism.web.service: Service RestartSec=100ms expired, scheduling restart.
Feb 05 19:38:10 macmini systemd[1]: snap.photoprism.web.service: Scheduled restart job, restart counter is at 271.
Feb 05 19:38:10 macmini systemd[1]: Stopped Service for snap application photoprism.web.
Feb 05 19:38:10 macmini systemd[1]: snap.photoprism.web.service: Consumed 6.044s CPU time.
Feb 05 19:38:10 macmini systemd[1]: Started Service for snap application photoprism.web.
I must admit docker privileged mode and full systemd inside it is not easy to run, for example I am getting this mount issue installing any snap while platform snap is working:
Feb 06 09:50:19 borisdesk systemd[1]: Mounting Mount unit for photoprism, revision 180…
Feb 06 09:50:19 borisdesk mount[2290]: mount: /snap/photoprism/180: failed to setup loop device for /var/lib/snapd/snaps/photoprism_180.snap.
Feb 06 09:50:19 borisdesk systemd[1]: snap-photoprism-180.mount: Mount process exited, code=exited, status=32/n/a
Probably related to the host OS (latest Ubuntu), what host OS are you using?
Our build system docker in this mode but host OS is very minimal Debian install.
I would suggest trying Virtual Box where at least we can a proper isolation.
Host OS is debian bookworm.
I have zero experience with VirtualBox so I would be reluctant to try.
What I don’t fully understand: Why was it necessary to run mariadb in a separate container? Installing photoprism required this container to be running (without it I got the same error messages on snap install photoprism as before). Reading in the photoprism docs I find a lot of stuff about migration issues with mariaDB. The backup of photoprism that I restored is coming from a syncloud container that worked well without the mariadb container.
I think I had users complaining about sync issues also sqlite is usually recommended for testing on small databases.
The best way to use Suncloud is of course on bare metal, like old PCs or smal devices like Intel NUCs.
I will try to get docker running on debian in virtual box to see if that helps to reproduce your issue.
I wanted to run Syncloud bare metal on my old mac mini. But (I guess because it is an apple device) I could not boot the Syncloud image (as far as I remember there was an apple boot manager which declined to boot from the internal HD with the Syncloud image). So with some haggling I managed to overcome the apple boot-manager and install debian from an usb stick and now it is basically doing nothing but running syncloud in a docker container.
If you see a possibility to install Syncloud bare metal from an external device and then transfer it to the internal HD to start from there I would be happy to give that a try.
Ok it makes more sense now.
Can you try imstalling Syncloud on your host debian using this instruction: GitHub - syncloud/rootfs: Syncloud rootfs
I did not work. This is one part of the output after running install.sh which seems to indicate an error:
+ systemctl start snapd.service snapd.socket
+ snap --version
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x270e0 pc=0x270e0]
runtime stack:
runtime.throw({0xe41cf1?, 0x36c87af8?})
/usr/local/go/src/runtime/panic.go:992 +0x71
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:802 +0x389
What debian did you install?
Also what is the model name of your mac mini?
Debian GNU/Linux 12 (bookworm) from debian.org - Netinst - AMD64
Apple macmini4,1 (Mid-2010)
Ok, have you tried installing other apps directly from debian apt repo, are they working fine?
You said docker is fine, can you install some docker based projects to see if they are fine.
Let me test syncloud install on bookwarm to exclude debian related issues as I am still thinking it is hardware related but who knows.
There was Evolution Mail Server running (without docker) and Gnome is running. And I have (again) Syncloud running under docker. This works fine (except photoprism).
When I tried to remove apache2 for the rootfs installation (as described in github) apt-get told me apache2 is not installed. But I can still see it running in processes. And I tried to install syncloud/rootfs as the root user. I guess that was ok?
apache2 is not installed. But I can still see it running
Probably it is called differently now.
And I tried to install syncloud/rootfs as the root user. I guess that was ok?
Yes, root is required
OK, I was able to install on debian 12, can you try installer from rootfs again please (GitHub - syncloud/rootfs: Syncloud rootfs)?
It is installed now, but the device activation failed.
I could register the device with my syncloud.it account, it is shown as activated (green dot) under www.syncloud.it.
But setting a device password failed with an Error
I restarted platform with
snap restart platform
but the result is the same. Is there a way to create device credentials from terminal?
You also need to update platform
snap refresh platform