Posts by bkeadle

    I had OMV running as a VMware VM. I migrated the VM to another (non-VMware) VM host, and now I do not have any network interfaces.


    lspci shows the Intel interfaces that the VM is configured for. (though, they should be E1000 virtual NICs) I've tried changing the guest VM's nic to a Realtek, but still no-go.


    How do I add/change/update network interfaces?

    I'm seeing the same thing for another iSCSI target to a Linux client, correctly showing it as an ext4 partition.


    These appeared after having rebooted, and having done an "mdadm --assemble --scan".


    So, this bug is just a presentation issue, and not indicating a problem then? As long as the /dev/md4 shows clean, my mirror is "healthy"?

    I used a print screen to show the OMV RAID Management screen, along with the putty output.


    Correct, the 'cat /proc/mdstat' doesn't show any problems, but what's up with the /dev/md4p1 showing under RAID management? /dev/md4 is an iSCSI block target for a Windows client. I do see that /dev/md4p1 appears under File Systems as an ntfs volume (created by the Windows client), but I didn't expect to see it in either RAID Management or File Systems. Is that normal?

    I had rebooted my OMV, and was surprised to find my RAID devices gone. Fortunately using this command *seemed* like it restored the /dev/md4 target


    Code
    mdadm --assemble --verbose /dev/md4


    But now I see a /dev/md4 showing in a clean state, and a /dev/md4p1 in a false state (see attachment). How do I clean this up? I can't tell if the Mirror is actually healthy or not. The 'mdadm --query --detail' and '/proc/mdstat' seems to report that it is.


    I had another RAID device that was similar, and thought that since the one looked right, I could delete the /dev/md#p1 - not so! Doing that made both disappear

    Well, I'm not getting a user list in short order! What I did was modify /usr/share/openmediavault/engined/rpc/usermgmt.inc thusly:


    /**
    * Enumerate users.
    * @param type The user type, e.g. system, normal or all.
    * @return An array containing user objects with following fields:
    * name, UID, GID, comment, home directory, and shell program,
    * last changed, minimum, maximum, warn, inactive, expire and
    * reserved.
    ...
    if (TRUE === $append) {
    $result[] = array(
    "name" => $user->getName(),
    "uid" => $user->getUid(),
    "gid" => $user->getGid(),
    "comment" => $user->getGecos(),
    "dir" => $user->getHomeDirectory(),
    "shell" => $user->getShell(),
    "lastchanged" => $user->getLastChanged(),
    "minimum" => $user->getMinimum(),
    "maximum" => $user->getMaximum(),
    "warn" => $user->getWarn(),
    "inactive" => $user->getInactive(),
    "expire" => $user->getExpire(),
    "reserved" => $user->getReserved(),
    "groups" => $user->getGroups(),
    "system" => $system
    );
    }
    }
    return $result;


    Interestingly, even though the email Comment Groups is not shown on the Users page, if I open the user, I *DO* see the comment field and the Groups memberships in Groups tab of the user.


    So, presumably all the information trying to be retrieved in the array is excessive...but, is it necessary?

    Ah ha! donh I found notes from 4/8/2016 when I was fighting this issue before. Perhaps this will ring a bell and help you suggest a resolution:


    /usr/sbin/omv-rpc "UserMgmt" "getUserList" '{"start":0,"limit":null,"sortfield":null,"sortdir":null}'


    does in fact return a user list after 65 seconds, but presumably not before nginix times out with the 504 error. Not sure what's taking so long when wbinfo -u returns a full list immediately.


    /usr/sbin/omv-rpc "UserMgmt" "getGroupList" '{"start":0,"limit":25,"sortfield":"name","sortdir":"ASC"}'


    returns the group list in just a couple seconds.


    My notes say:

    But that's not making much sense to me now.

    Followed the threads best I could, but it was a fail.


    realmd apparently not available for v2.x - but proceeded anyway thinking perhaps it wasn't necessary. Maybe it is.


    I put things back the way I had it. getent passwd returns users immediately, as does wbinfo commands. But, on Access Rights Management/User, it spins "Loading..." and eventually gives a 504 Gateway Time-out error. Is there a setting that I can extend the wait so perhaps the users will show up...just to confirm it's a time out issue?


    However, now when I select Group, it returns the local groups instead of my AD group. Previously, it at least returned my AD group. sssd service is stopped.

    winbindd cache setting is already set to 6 minutes. Seems like this might be some nginx setting to wait longer for results? But again, wbinfo queries for users come back almost immediately.


    I see a reference to sssd in these forums, but I don't have /etc/sssd/sssd.conf. Is that some missing piece I *need*? Again, the Group return, but Users will eventually produce an nginix 504 Bad Gateway error.


    What more can I provide to help assist?

    When I have Directory Service enabled, I have frequent Bad Gateway 504 errors. Presumably this has something to do with user-related dialogs, easily reproduced by selecting Access Rights Management/User. wbinfo returns users nice and quick, but within OMV Web Interface, it's very slow, and usually will time out. If I click on Group, it returns after several seconds with groups in AD. I wouldn't say the my AD is very big: 426 groups and 424 users

    I have 3 different OMV servers, all 3 seemingly configured similarly. I can go through the normal process of creating a publicly accessible share, and able to access without being prompted for a password on 2 of the servers, but the third does not behave the same. I can enter .\nobody as the username and I can access the share fine. However, I need to access without being prompted.


    One difference is, that though all 3 have Directory Service enabled (thus security=ads in Extra options set on SMB/CIFS), when I click on Access Rights Management/User, there is a long delay while the User list from AD is queried on the 2 working servers. On the third server, however, it returns the local user list, apparently never querying AD. This would seem to be where the disconnect might be.


    I've been racking my brain on this for several hours, and I'm at my wits end!