hire a commercial developer
That is not feasible and not what I want for the project.
hire a commercial developer
That is not feasible and not what I want for the project.
You may have a look here how to fix broken package situations.
You have to use environment variables to customize the configuration that is generated by openmediavault. See https://docs.openmediavault.or…l#environmental-variables for more information. The ClamAV relevant variables are prefixed with OMV_CLAMAV_.
How did you install? Did you use the OMV ISO image? Did you set the correct boot order in the BIOS? Is the disk that contains the OS in the list of the boot devices in the BIOS?
Are there are any plans forking OMV with configurable notification settings?
Wouldn't it simply be enough to contribute code that implements the configuration of the messages for APT? I never said that I don't want to see this functionality in OMV.
Unfortunately, that makes me very sad. This post makes me even sadder. Is it better to fork a project before submitting even one line of code as a contribution?
But the whole thing is honestly no longer necessary. I have finished my experiment to see how long it takes for the OMV community to contribute code to add this functionality. Unfortunately the experiment failed as absolutely nothing came from the community.
I've had the code lying around for a while and today I started to adapt it for the next version... Even before I saw this post here.
You can find the PR here: https://github.com/openmediavault/openmediavault/pull/1845
I don't know who is starting this service, but the Debian package from openSUSE Build explicitly disables it and OMV does not enable and start it as well.
Code from https://build.opensuse.org/sou…ve/onedrive/debian.tar.xz
override_dh_installsystemduser:
dh_installsystemduser --no-enable
override_dh_installinit:
dh_installinit --no-start --no-enable
root@openmediavault:/home/alfonso# omv-onedrive-auth
bash: omv-onedrive-auth: command not found
If the command is not there, then the plugin is not installed correctly.
this really needs to be something to fix here on your platform to disable / remove this default systemd service if it is ever created.
I'm doing my best, but I'm getting tired of having to do everything myself. There have been almost no contributions from the community since the start of the project. At some point it's over.
Run systemctl stop onedrive and systemctl disable onedrive as root user.
Have a look for containerized solutions. Installing additional software like that might break OMV because such solution will surely override the OMV webserver or will not harmonize in parallel.
The mount point is constant.
There is no such variable or feature that replaces that variable with the mount point.
There is an extra options field in the rsync job form page to append additional command line args.
The user admin is only for the UI.
To log into the TTY you need to use the root user which password you set during the installation.
When was it released?
A new plugin package has been released.
The OMV package repository has a pre-release and a community-maintained sub-repository. But to use that the code must be available in the OMV GitHub repository.
The problem is this: New size too large to be expressed in 32 bits
So you are on a 32bit platform? Please note that this is not supported officially by OMV anymore. If possible, switch to the 64bit version if your hardware supports that.
You can contribute plugin code to the OMV GitHub repository at https://github.com/openmediava…ediavault/tree/master/deb.
Add --display-running-config to assist what configuration is actually being used and where are application files being accessed from
This helped me to identify the problem. Thx
Update systemd service file for correct exit not to restart code (126) when a --resync is required. The application should stop constantly restarting when exiting with a 126 value
The problem here is a strange problem of the Debian package from SUSE build service. If the old package is replaced bythe 2.5.2 one, it seems the old onedrive.service is not deleted and survives the package upgrade. Because of that i had a mixture of old and new systemd unit files. Using the onedrive@.service file will result in the expected behaviour.
Remove all config options that have been added, that are equal to their application 'default'. It is pointless having these set.
If the config file is manually generated then i am with you, but OMV is using a configuration management and orchestration tool to deploy the configuration. I'm too lazy to check if the config option matches the default or not. Second, if i'm doing a check, then i have to monitor the defaults per every update because they might change.
Plugins are delivered via the OMV package repository.