dlandon

I updated MariaDB on my main instance of ownCloud and after an update and a restart this is the log: ownCloud startup: PHP 7.4.33 *** Running /etc/my_init.d/999_advanced_script.sh... *** Booting runit daemon... *** Runit started as PID 692 Oct 31 07:28:24 ccc2338ece1c cron[699]: (CRON) INFO (pidfile fd = 3) Oct 31 07:28:24 ccc2338ece1c cron[699]: (CRON) INFO (Running @reboot jobs) ownCloud startup: MariaDB 10.11.19-MariaDB-log 261031 07:28:24 mysqld_safe Logging to '/config/database/ccc2338ece1c.err'. 261031 07:28:24 mysqld_safe Starting mariadbd daemon with databases from /config/database mysqld is alive Oct 31 07:28:29 ccc2338ece1c mariadb: MariaDB system-table upgrade completed. Oct 31 07:28:29 ccc2338ece1c mariadb: This installation of MariaDB is already upgraded to 10.11.19-MariaDB. Oct 31 07:28:29 ccc2338ece1c mariadb: There is no need to run mysql_upgrade again. Oct 31 07:28:29 ccc2338ece1c mariadb: You can use --force if you still want to run mysql_upgrade You can see php 7.4.33 and MariaDB 10.11.19. The last step to get to supported php 8.x will come when I update to ownCloud 11. Until the apps are compatible, I will hold off on that. Too many are not yet compatible. @Samsonight Hopefully this addresses your concerns about ownCloud security and EOL php and MariaDB. Thanks for letting me know about these issues with the ownCloud container.

I released a new docker container. My main server ownCloud updated and is running. *** Running /etc/my_init.d/30_redis_server.sh... Starting redis-server: redis-server. *** Running /etc/my_init.d/40_get_owncloud.sh... *** Running /etc/my_init.d/50_set_config.sh... *** Running /etc/my_init.d/60_gen_ssl_keys.sh... [ssl] Generating self-signed keys in /config/keys (missing/empty cert/key), you can replace these with your own keys if required [ssl] Self-signed certificate generated (valid 825 days, SAN=localhost/127.0.0.1) *** Running /etc/my_init.d/70_initialize_database.sh... *** Running /etc/my_init.d/80_first_run.sh... Oct 30 10:47:33 8d8f31f9381f crontab[644]: (root) REPLACE (root) ownCloud startup: PHP 7.4.33 <================= *** Running /etc/my_init.d/999_advanced_script.sh... *** Booting runit daemon... *** Runit started as PID 651 Oct 30 10:47:33 8d8f31f9381f cron[658]: (CRON) INFO (pidfile fd = 3) Oct 30 10:47:33 8d8f31f9381f cron[658]: (CRON) INFO (Skipping @reboot jobs -- not system startup) ownCloud startup: MariaDB 10.6.23-MariaDB-0ubuntu0.22.04.1-log <================= 261030 10:47:33 mysqld_safe Logging to '/config/database/8d8f31f9381f.err'. 261030 10:47:33 mysqld_safe Starting mariadbd daemon with databases from /config/database Notice the two highlighted log lines. These give you the php and database versions running on your system. I will wait a while before updating my database. I won't update ownCloud until the apps I use are updated to run on ownCloud 11. Again I caution you that updating to ownCloud 11 with get php 8.3, but the apps not being updated may limit your ability to use ownCloud as you wish.

I've been testing the new docker container and it is looking good. The one thing I find after upgrading my test server to ownCloud 11 is that there are a lot of apps I use like the 'Next Backup' that are not compatible with ownCloud 11 yet. I will hold off upgrading to ownCloud 11 until more of the apps are updated. You should evaluate what apps you use and see if they are ownCloud 11 ready before making the upgrade to ownCloud 11. You can check them at the ownCloud Marketplace here.

I'm working on a new container that will handle the existing ownCloud installations and install ownCloud 11 and MariaDB 10.11 for new installs. The new container will keep an existing ownCloud version and MariaDB 10.6 as it is. You can then update the MariaDB to 10.11 and ownCloud to 11.x when you are ready. Owncloud recommends you are updated to ownCloud 10.16.x before updating to ownCloud 11.x. The new container will adjust the php version to what the installed ownCloud version requires. I believe the best migration path for minimal probems would be: Make a backup of your appdata/ownCloud/ directory before performing any update. Update the docker container when it is avaiable. This step by itself addresses the latest php security issues but leaves you using php 7.4 that is at EOL. Run ownCloud for a while to be sure there are no issues. Update the MariaDB database to 10.11. This step updates MariaDB to the latest supported version. Again, run ownCloud for a while to be sure there are no issues. Update to ownCloud 11.x. This step updates to php 8.3 and off of php 7.4 that is EOL. The upgrade for MariaDB and ownCloud are documented in the second post of this forum thread. The steps may change before final release of the updated container. I have done some initial testing and the steps all worked. I'll release a new ownCloud container after some more testing.

Updated ZoneMinder Docker image I’ve updated the image to use Ubuntu 22.04 (Jammy), PHP 8.4, and ZoneMinder 1.38. I tested a fresh install and an update using existing appdata. The database updates completed successfully. I also verified the web UI over HTTP and HTTPS, both directly and through Tailscale. Back up your existing appdata before starting the updated image for the first time. I’ll be spending more time with the new ZoneMinder settings and will share anything noteworthy.

Please hold off on upgrading existing ownCloud installations to 11.x I’m developing a new container that will support both existing installations and new ownCloud 11.x installations. Please don’t manually upgrade an existing installation to ownCloud 11.x until the new image and its migration instructions are ready. The current container is built around ownCloud 10.x, PHP 7.4, and MariaDB 10.6. Changing the ownCloud version before the container can provide the matching PHP and database runtimes could leave the installation unable to start. The plan is to use one image that selects the PHP runtime based on the installed ownCloud version. A new installation will start with ownCloud 11.x, PHP 8.3, and MariaDB 10.11. Existing installations can continue using their ownCloud 10.x version, PHP 7.4, and MariaDB 10.6 until the user chooses to upgrade. Both PHP versions will be included in the image, avoiding a lengthy PHP installation during container startup. The ownCloud application upgrade and the MariaDB engine migration will be deliberate user actions. The container will not silently migrate an existing database. I’ll provide instructions for backing up and migrating the database when the image is ready.

I set it up specifically so you could install the version of LMS that was best for you and the level of risk you wanted to take.

Look at the first post on installing the latest (9.1.1), stable (9.1.2) and dev (9.2.0) versions. They were all updated yesterday.

The PHP security issue has been addressed in the updated image posted today. The larger work is safely modernizing the rest of the stack without breaking existing installations. ownCloud tightly couples its releases to specific PHP versions. Changing PHP to 8.x in the image would prevent older ownCloud versions that require PHP 7.4 from running. The ownCloud upgrade and PHP change need to be tested together, with users able to choose when to make that major-version move. MariaDB also needs attention: the image’s MariaDB 10.6 line is now end-of-life. ownCloud’s 10.16 documentation recommends MariaDB, but its Ubuntu 22.04 example is 10.6.12 and it doesn’t name a currently maintained target. Upgrading an existing database requires preparation in ownCloud, a backup, and MariaDB’s upgrade procedure; it isn’t just a package-version change. ownCloud’s database upgrade guide describes those steps. I’ll plan on the MariaDB upgrade while preserving the current ownCloud/PHP combination, then evaluate the ownCloud/PHP 8 migration separately. I don’t want a container rebuild to force existing users into a major ownCloud upgrade.

After updating the container, you can verify the installed versions with: docker exec ownCloud dpkg-query -W -f='${Package} ${Version}\n' php7.4-fpm libapache2-mod-php7.4

I’ve rebuilt the ZoneMinder container on Ubuntu 22.04 Jammy and included the PHP security fix. PHP 7.4 remains in this build; the move to PHP 8 will be evaluated separately. The build now checks that both php7.4-fpm and libapache2-mod-php7.4 are version 1:7.4.33-31 or newer. After updating the container, you can verify the installed versions with: docker exec Zoneminder dpkg-query -W -f='${Package} ${Version}\n' php7.4-fpm libapache2-mod-php7.4

Thanks for the detailed report and for identifying the PHP issue. I’m rebuilding the existing container so the PHP security fixes are included in the image. I’m also adding a build-time version check to prevent an image from being built with the vulnerable PHP package. Users with automatic OS updates enabled should restart their container and verify the installed php7.4-fpm version. Moving to a PHP 8.2-based ownCloud image is a separate effort. It will require compatibility testing, so I’m keeping this security rebuild on the existing PHP version while I evaluate that change. I also saw your report about the web updater timing out while creating a checkpoint. I haven’t addressed that in this rebuild; I’ll review the nginx timeout handling separately. I recommend using the container’s Tailscale support to access ownCloud privately, rather than exposing it directly to the Internet.

The Event Server was having issues on the initial Tailscale implementation release connecting to the Event Server port 9000. Today's release fixes the Event Server notifications in ZmNinjaNg.

Tailscale support addedThe ownCloud container now supports Tailscale for secure remote access without requiring public DNS, router port forwarding, a static public IP address, or a publicly managed SSL certificate. I have tested the following through Tailscale: ownCloud browser access ownCloud Android application access File uploads and synchronization Tailscale-managed HTTPS certificates Because ownCloud uses an internally generated self-signed certificate, set the Tailscale Serve Target to: https+insecure://localhost The Tailscale WebUI and client URLs must not include the container’s :8443 port. Including the port connects directly to ownCloud and presents its self-signed certificate instead of the trusted Tailscale certificate. The container’s Tailscale hostname must also be added manually to the trusted_domains array in ownCloud’s config.php. Complete setup, client configuration, certificate, and rollback instructions have been added to the first post in this thread.

Tailscale support addedThe ZoneMinder container now supports Tailscale for secure remote access without requiring public DNS, router port forwarding, a static public IP address, or a publicly managed SSL certificate. I have tested the following through Tailscale: ZoneMinder browser access ZoneMinder API access zmNinjaNG access Tailscale-managed HTTPS certificates ZoneMinder uses an internally generated self-signed certificate, so the Tailscale Serve Target must be set to: https+insecure://localhost This allows Tailscale Serve to connect to ZoneMinder internally while presenting a trusted Tailscale certificate to clients. Complete setup and testing instructions have been added to the first post in this thread.

The problem I was having with this plugin is I had no way to test the plugin since I don't have a Windows server. As you found out, there was a lot lacking and some bugs. I took it down because I didn't want anyone using it in it's current form with all the issues and bugs I had no way to reasonably resolve. I will make my GitHub Public Archive and add a link to your GitHub with a note the work is carrying on there. Thanks for the recognition of the work I did. Feel free to carry on the effort.

Thanks for the information. The process listing confirms that LMS and the Spotty authentication process are both running as nobody: nobody 668 ... /usr/bin/perl /usr/sbin/squeezeboxserver --u nobody ... nobody 712 ... /spotty-x86_64 ... --authenticate The /config and /config/cache directories are also correctly owned by nobody:users. So the Docker container appears to be setting the ownership and running LMS correctly. I don't see anything at the container level that would explain why Spotty's credentials.json is being created as root:root. I'd suggest continuing this with the Spotty developer since the Spotty authentication process itself is running as nobody.

Give me the output of these commands: docker exec LyrionMusicServer ls -ld /config /config/cache and docker exec LyrionMusicServer ps -eo user,pid,ppid,args

The -13 error is a credentials issue. Check your credentials.

There is way to trick UD and get it to do what you want. I have a UD disk mounted: With file contents: I add remote shares for the UD disk folders I want to share: You can change the name of the share by changing the "Mount Point". Be sure to turn on the share switch. So then you see this in the Windows Shares: When you add the Remote Share, you have to enter the share folder manually because the scan for the shares only shows the top level share. You can add any folder on the UD disk. You can do the same thing to a remote share by adding another remote share that points to the remote share sub folders. Add a main remote share "192.168.0.3_Family Files/" with Mount Point "192.168.0.3_Family Files". Be sure to enable sharing. Add a remote share "192.168.0.3_Family Files/!Home Videos/" with Mount Point "Home VIdeos". Be sure to enable sharing. Add a remote share "192.168.0.3_Family Files/!Pictures/" with Mount Point "Pictures". Be sure to enable sharing. And any others you want. You will then see "Home VIdeos" and "Pictures" in the network shares. You need to add the sub folders manually in the add a remote share dialog.

Your diagnostics show the drive itself is not the problem. The partition table was created successfully, but the format failed because the plugin is trying to execute: /usr/sbin/mkfs.exfat On current Unraid releases, mkfs.exfat is actually located at: /sbin/mkfs.exfat The important line in your log is: Format failed: sh: line 1: /usr/sbin/mkfs.exfat: No such file or directory So the partitioning completed successfully; only the filesystem creation failed because the executable path is incorrect.

I submitted a PR to fix this issue.

I have a few suggestions that might simplify integration: Limit custom share paths to /mnt/user. The /mnt/disks and /mnt/remotes paths are managed by Unassigned Devices (UD). Those mount points can appear and disappear as devices are mounted, unmounted, attached, or detached, so they are not as stable as Unraid user shares. UD already manages SMB sharing for those paths, so I don't think they should be offered as Custom SMB Share locations. Use a working configuration in /etc/samba. Currently the custom share configuration is stored on the flash drive at /boot/config/plugins/custom.smb.shares/smb-custom.conf and included via the "SMB Extras" mechanism. I think it would be cleaner to keep the persistent configuration on the flash drive, but generate a working copy in RAM at /etc/samba/smb-custom.conf and include it directly with: 'include = /etc/samba/smb-custom.conf'. That's consistent with how Samba's runtime configuration is managed elsewhere in Unraid.

Done.

How does it show in UD? Screen shot?