Sinister Crayon

Having a small but interesting challenge with my container. I have some sync jobs set up and they all work great, but every time I restart the container it "forgets" the settings for the port # being shared and the "Use PnP Port Mapping". This is annoying because every time I have to remember to go in and set the port to 55555 and disable the PnP Port Mapping as some firewalls in my environment are set up to only allow this traffic through this port. I am wondering if the settings file is corrupted somehow but don't want to just delete it if it's going to lose my jobs as I don't feel like recreating those too. Thoughts? UPDATE: Fixed it. Just on a whim I deleted the "perms.txt" file and restarted the container. All fixed now. So anyone else hitting this issue try that

Yup.... exactly like that. Thank you for your prescience...

Probably more of a feature request, but any possibility of adding an option (maybe behind a "Yes I really know what I'm doing" checkbox) to backup the appdata without stopping containers? The use case would be where you're using a filesystem that can support snapshots like BTRFS or ZFS, nominally on a cachepool. In my case I could use ZFS so could use the pre/post backup scripts to take a quick snapshot of the appdata filesystem, then direct the backups to only backup the /mnt/user/appdata/.zfs/snapshot/$snapname directory then delete the snapshot when done. While stopping the containers isn't a huge deal for me there are a couple I prefer not to stop and leave in the skip bucket right now. This would enable me to take a "crash-consistent" backup of those containers that'd be great for restoration in a crunch. This would be amazing for database containers for example or containers that run long-running jobs you don't want to stop.

I'm fully aware of the usage of containerization. I am just reporting some minor issues and a fix for them. In your images the "Deployment" feature of recent versions of Bacularis doesn't work. If you add "expect", "pgp" and "ssh" to your images you'll find that it works consistently. This should be a pretty minor change but yes I'm happy to fork your code and do my own images. I'm just reporting this so that if other people report the same problems you'll know where to fix them. I just hit the same problem again with the feature in the Bacula 13 image with Postgres and the same fix resolved it. While the "Deployment" feature is not a required thing for running Bacula, it IS a feature in the Bacularis code that is called out in the documentation as to how to deploy and maintain clients more easily. As a result, anyone following the stock documentation for Bacularis who doesn't have experience with Bacula in general will find your image broken as a result. https://bacularis.app/doc/deployment/basic.html I'm just trying to provide useful feedback that I hope will be helpful in future versions and development. I know you're just one person which is why I'm trying to provide you a solution to the problem that I found rather than just demanding that it be fixed. Hope this all helps

Just wanted to provide some more feedback. Decided to start from scratch with Postgres as my database instead of SQLite. Cleaned up the old config and deployed the 15 image with Postgres. Can confirm I am having the same issue as @professeurx that despite defining DB_Host, DB_User and DB_Password it cannot find the Postgres database. I can connect fine from other remote systems. Tried adding DB_Port and the problem persists; says ==> Could not connect to database. Please check DB Settings: Host, User, Password, Port. exiting Edit to add: Switched to the 13 image with Postgresql and it seems to work OK.

I figured out my deployment problem... I am using the API deployment from the left hand side (bottom option) that puts a Bacularis API setup on the system so you can install, fix and uninstall components from the GUI. My problem turned out to be something in an NGINX configuration that was already installed on that machine... it's still broken and not sure why. Tried another machine and it worked OK. My feedback about the image still stands... I went into the console and did "apt update; apt install -y ssh; apt install -y pgp" and that allowed me to use the deployment API successfully.

Wanted to report; installed sqlite version 15 as a clean install. Deployment for remote clients doesn't work and at a minimum it appears the image needs at least SSH and PGP and all their dependencies installed into the Docker container before it'll even begin the process. Once I get it all installed I'm getting the same problem as @professeurx with not being able to connect and getting a CURL error when installing the client after getting the API deployed. I noted that when I browsed to the API instance on the target machine it prompted for a username and password, but none of the username or password combinations that were entered in the OS Profiles appears to work. I suspect something else is broken there but not sure what?

24 hours later the problem appears to have resolved itself? Not sure if it was because of me reinstalling libffi by hand but the GUI appears to be working perfectly now without the need for a reboot (never got to it last night and was going to do it this morning). Attached a new diagnostics file for comparison. zbox-diagnostics-20230814-0709.zip For the record, after reinstalling libffi everything seemed the same... refreshed, cleared cookies and so forth with no change. It just appears to be working fine this morning.

Yeah I don't see a solution either. I've tried both Firefox and Chromium (on Linux) as well as Chrome on Windows... same result. This is not the first time this has occurred for me either and it seems to be a bug that's not yet fixed in the code... as it stands it happens infrequently enough that it doesn't really bother me much but is an irritation. Still, hope we can get somewhere now that we have diagnostics while it's occurring.

Update: had time to troubleshoot a bit this morning and manually installed libffi from the Ubuntu deb package by extracting it on a different machine. Ran diagnostics and the zip file is attached. I have not yet rebooted the machine but that's on my list today (probably late today). Let me know if you need anything else from this machine before I do it. zbox-diagnostics-20230813-0656.zip

I'm getting this, too. It's happening right now. I cannot run diagnostics... spins and never downloads anything. Running "diagnostics" from the command line returns /usr/bin/php: error while loading shared libraries: libffi.so.8: cannot open shared object file: No such file or directory