Posts by graealex

It'd be nice if they were.

Brute forcing would still get stopped dead in its tracks if the time period for account lockout wasn't infinite.

Got locked out again from my web admin interface. I know, I know, faillock --user admin --reset or omv-firstaid.

But what's the right way to set the amount of time after a lockout is reset, and the number of required failed attempts? I'd rather not mess with /etc/security/faillock.conf or /etc/pam.d/common-auth and potentially break everything.

Thank you.

I would still ask the question if virtual network interfaces can be filtered in the display of the dashboard. For example, in Jellyfin I have:

<IgnoreVirtualInterfaces>true</IgnoreVirtualInterfaces>
<VirtualInterfaceNames>
  <string>veth*</string>
  <string>br-*</string>
  <string>vEthernet*</string>
  <string>docker*</string>
  <string>lxcbr*</string>
  <string>cni-podman*</string>
</VirtualInterfaceNames>

Example why this is kind of not useful anymore:

Quote

It is difficult to use OMV's nginx as a reverse proxy and I wouldn't recommend doing it

It's very easy, you just drop a file in /etc/nginx/openmediavault-webgui.d/ and have your application running at the normal server URL.

Quote

When using NPM or traefik, you aren't useing OMV's nginx

True, that's why I separated that approach.

Quote

If someone is using nextcloud in a container, the upload limit of OMV's nginx instance wouldn't apply.

Is that so when using OMV nginx as reverse proxy, though?

Quote

Normally no file is being uploaded to OMV

Depends. Plenty of people installing Nextcloud on their systems, and then mapping the container into their normal URL space. Although they might go the reverse route and use Traefik or Nginx Proxy Manager as their main endpoint.

Quote

Scolded by who?

Thread

OneDrive looping with error

Since not too long, OneDrive plugin keeps looping after start and fails with the following error:
(Code, 3 lines)

The content of the file /var/cache/onedrive/config:
(Code, 22 lines)

openmediavault 7.7.6-1
openmediavault-onedrive 7.1.4-3
onedrive Version: 2.5.5-1+np1+1.1

I assume I am not to mess with /var/cache/onedrive/config as indicated by the header. I changed it anyway and put a # in front of verbose = "true", understanding that it'll get overwritten eventually.

After having to do omv-onedrive…

graealex

May 7th 2025

Quote

I said I will think about it

I appreciate it. I think 25M is way off when comparing normal HTTP(S) interactions vs. file uploads. There has never been a good compromise available in that regard. That's not your fault, just how HTTP(S) has been caught between usage trough browsers, and usage through file transfers.

Quote

25M

Using WebDAV to sync my camera/pictures folder to my NAS. Obviously any video that's not just 3 seconds will easily go over 25M. If anything, my example is also bullshit, since 2048M still left 3 files not being able to sync, since they were larger than that.

Also OMV_NGINX_SITE_WEBGUI_CLIENT_MAX_BODY_SIZE is one of those "not documented and you also should not use it if you don't know 100% what you are doing" options. Which I got scolded before when I used such an option.

Basically the title. When using WebDAV to sync files, there is a maximum file size, defined by NGINX option client_max_body_size. Increasing it can be done by inserting the following example in "Extra options":

client_max_body_size 2048M;

This should be a GUI option, since it is essential for a protocol meant for data transfer. If it was a GUI option, it would make it a lot easier for users to identify this being the cause of a problem when trying to upload data via WebDAV.

Quote from votdev

The list command lists all existing environment variables.

Thank you. Unsetting the variable produces the following entry in the config file:

verbose = "0"

This does not cause an error with onedrive, though. Why is it now "0" instead of "false" (where it had been "true" before)?

Quote from votdev

you need to read the documentation carefully how to use the omv-env command

Yes I am at fault the plugin produces an invalid configuration file by just setting an innocent environment variable that is supposed to just enable verbose mode. Clearly.

Also this!?

root@graealexhd1:~# sudo omv-env list | grep OMV_ONEDRIVE_VERBOSE
OMV_ONEDRIVE_VERBOSE
root@graealexhd1:~# sudo omv-env unset OMV_ONEDRIVE_VERBOSE
root@graealexhd1:~# sudo omv-env list | grep OMV_ONEDRIVE_VERBOSE
OMV_ONEDRIVE_VERBOSE

Am I too stupid to unset an environment variable?

Big oooof about the toxicity here. "The user is dumb, they should read the documentation" - well, the documentation specifies to set OMV_ONEDRIVE_VERBOSE to enable verbose mode. Which I did at some point in the past probably. Mea culpa for using a provided debugging feature.

Quote from votdev

And to be honest I don't care because this is a user error and not a bug in my code. I just wanted to show the user where the problem lies.

I wholeheartedly disagree about "user error". If setting an environment variable leads to the plugin generating an invalid config file, it is a bug in the plugin code.

Thank you though for the workaround, I will remove the environment variable. It would be nice if there was a way to enable verbose mode in a simple way, since that is a reasonable thing to do - enable more logging in case other problems pop up. For me the plugin has always worked great

Since not too long, OneDrive plugin keeps looping after start and fails with the following error:

May 07 23:26:46 xxx onedrive[691796]: Reading configuration file: /var/cache/onedrive/config
May 07 23:26:46 xxx onedrive[691796]: Invalid value for key in config file: verbose
May 07 23:26:46 xxx onedrive[691796]: Configuration file has errors - please check your configuration

The content of the file /var/cache/onedrive/config:

# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.
enable_logging = "true"
verbose = "true"
sync_dir = "/srv/dev-disk-by-uuid-4faa5941-08a5-4ef9-8e4d-f796723d162e/onedrive/"
sync_dir_permissions = "750"
sync_file_permissions = "640"
local_first = "false"
no_remote_delete = "false"
cleanup_local_files = "false"
download_only = "false"
upload_only = "false"
skip_dotfiles = "false"
monitor_interval = "43200"
monitor_fullscan_frequency = "12"
rate_limit = "0"
# Fix issues related to curl that is installed by Debian.
# https://github.com/abraunegg/onedrive/blob/master/docs/usage.md#compatibility-with-curl
force_http_11 = "true"
ip_protocol_version = "1"
# Do not display the warning message on startup.
disable_notifications = "true"

openmediavault 7.7.6-1

openmediavault-onedrive 7.1.4-3

onedrive Version: 2.5.5-1+np1+1.1

I assume I am not to mess with /var/cache/onedrive/config as indicated by the header. I changed it anyway and put a # in front of verbose = "true", understanding that it'll get overwritten eventually.

After having to do omv-onedrive --reauth since the service has been inoperable for too long, a sync was successfully started.

I would assume a single boolean flag is manageable. I could take a look at it, if it was something you'd find worthwhile to add (from past forum and Github threads, my impression was "no"). Although since my PR got merged, and users have the option of influencing it via the default mechanisms, I don't think it's super important.

I would even assume that most users don't care about, don't know about it, or outright leave IPv6 completely disabled, since it's additional hassle. I use IPv6 in the home lab since it is something to consider professionally, or at least with increasing urgency.

It would be an extremely simple addition. Since it influences address acquisition on a very basic level, I don't think it would be a superfluous addition.

Thank you, that is very useful. The only posts I could find were from people who also wanted to disable PE and got no answers.

I did the changes described by me above, but with the next update I will look into it again and probably follow your post/Github issue.

I don't agree with Volker though in that the GUI shouldn't have an option. I actually think a checkbox in the web interface would be by far the best solution.

I'm sorry to be this blunt. OMV enforces an option that isn't actually an option, since nowhere in the GUI can you actually choose. This also has absolutely nothing to do with router announcements. OMV injects the "ipv6-privacy: true" line and that causes privacy extensions to be active. The rest of your comment really has no bearing on that issue. This has nothing to do with netplan, and is all about OMV making non-defaults a default.

In the meantime, it is possible to disable IPv6 privacy extensions here by removing "ipv6-privacy: true":

/srv/salt/omv/deploy/systemd-networkd/netplan/files/ethernet.j2

/etc/netplan/20-openmediavault-en*.yaml

Not sure how long these changes last. I assume "ethernet.j2" gets replaced with any update of OMV.

I created a pull request to remove that bogus "ipv6-privacy: true" from getting created as a netplan YAML file, since it is not user-configurable.

Pull Request

Quote

You need to set accept_ra to no

Why would I want the server to not accept RAs? I obviously want SLAAC to keep working. Just create the address without randomization.

Quote

Why do you want to disable privacy addresses?

So the address remains static. Prefix doesn't change for me, but privacy extensions make the host address change. In this particular case I want it to remain static for debugging purposes.

Quote

If you use Windows, Windows is using them as well.

I obviously have privacy extensions disabled there as well. Besides, these are clients. The role of addresses remaining static is different for clients and servers. Anyway, my Windows clients all have the expected, static 3 IPv6 addresses. One GUA, one ULA, and one LLA.

While I generally am positive towards the "why would you want to do that?" question in regards to technical issues, disabling privacy extensions is a very simple and straightforward thing to do usually, doesn't require any "why" questions, and should be possible even when running OMV, if not through GUI options, then at least through configuration file defaults, as I tried here.

I am generally unclear about how OVM configures network interfaces, like how the options in the web interface are eventually passed through to the actual OS. All folders I visited so far had basically zero configuration files. You bringing up netplan helps me to look into it. If netplan overwrites manual defaults, then maybe that should be changed or be an option. I am really puzzled why OMV would actively set use_tempaddr without a user having manually set anything, when there's a default and an all option available that the user could set themself.