Importing User Fails

Background:

I have one very old Fedora 17 Linux machine that refuses to negotiate using SMB2 protocol with my RaspberryPi 4 OS Lite. This is the lowest supposedly common SMB protocol between the two. Yesterday I found that Fedora for whatever reason quietly disabled SMB2 in the version of Samba they shipped with that release. RPi 4 OS uses Samba 4.13 which can use SMB2 if configured to use it. But was never able to get these two to talk. Always getting protocol negotiation error. So I gave up on SMB sharing between these two and instead now trying NFS. The issue with NFS is that you must match UID/GID between machines or you get weird behavior. Sometimes files won't move/copy or if they will move/copy but you'll lose timestamps. In order to everything to work properly you have to match UID/GID between the machines.

So today on each machine I created what will be a known system account for use with OMV NFS like this:

pi@raspberrypi-nas:~ $ sudo useradd -r --uid 975 -U omvnfs
pi@raspberrypi-nas:~ $ grep omvnfs /etc/passwd
omvnfs:x:975:975::/home/omvnfs:/bin/bash
pi@raspberrypi-nas:~ $ grep omvnfs /etc/group
omvnfs:x:975:
pi@raspberrypi-nas:~ $ 

I go into OMV6 and try to import this user. It acts like it succeeded but no new user appears in the list of users. So is there some magic potion I'm not aware of here to get this user imported?

So I've tried this after reboot and this time I get:

500 - Internal Server Error
The user '975' already exists

But I don't see the user in the list.

That's not good. There's some distributions where regular users start at 500.

Bug opened: Bug #1285

Quote from Soma

Users creation should be done on the GUI, not on CLI.

OMV will create the user in a proper way and it will be above 1000.

Since you're running raspiOS, pi user is already id 1000.

This is a problem. Sure I can go to each client and create users. All will be above the UID_MIN. The problem is that none of that will work for NFS.
The only sure way to get NFS working is with a known system account that can be added to OMV and each client. That is why I chose the UID that I did. I had checked all my systems and none of them had anything down below 980 so 975 was chosen. There's no reason a system account can't be used for a user in OMV other than just an arbitrary reason. It's an artificial restriction that doesn't need to be there.

Quote from ryecoaaron

Yes it does. Otherwise, people could delete important system users. If you need to do system user level work, that is command line territory. And I don't know why nfs would care if it is a system level user.

No they couldn't. No package is going to use OMV to create its system user accounts.
You are free in any distribution to create system accounts for your own use. The point is that you then have known UID/GID's that match between systems. None of that occurs when you go creating regular user accounts. One system might have one user. The next might have ten thousand users.

Quote from ryecoaaron

This has nothing to do with packages. If the user shows up the user management tab in the web interface, a user could delete it not knowing what it does.

Sounds like you need ldap. And there is a plugin for that.

There's no way for a system user to show up in OMV unless the user imported the system account themselves and then obviously they know what it is for.

ldap does not guarantee that UID/GID between systems will be identical. ldap just adds complication that is unnecessary.

The only system accounts that need excluded are those down below 200. Anything else is fine.

Quote from ryecoaaron

OMV only shows users between UID_MIN and UID_MAX. There is no other logic to it. If you want your user at 200 to show up in the web interface, change UID_MIN.

Ummm, I'm sorry but it does unless there is a conflicting local user. (nsswitch.conf will determine behavior then). That is the whole point of ldap - central user/group names with consistent uid/gid. I use nfs for dozens of systems at home and don't have this problem.

So, change your UID_MIN to 200. 99.9% of OMV users don't care about this.

No, changing UID_MIN isn't the answer. That changes regular users. They don't need changed.
What needs changed is OMV looking at SYS_UID_MIN and SYS_UID_MAX.