Posts by jay

    that's the part that has to be wrong even in a windows domain environment it's <domainname>.local so for instance our school domain is schoolname.local for the school, however depending on what being done sometimes just the <domainname> without the local will work.

    We're using a real/valid domain. Maybe issue you're talking about is related to dns domain suffix search list in your environment?

    If you have DNS, most servers do the translation from any name in their table (to include aliases) to IP address.

    I don't have any ideas. Sorry.

    Rebooted the DNS server and it seems to have worked the bugs out. :)

    It's strange because I was able to resolve the FQDN for omvhostname from the clients just fine. Whatever. "did you try turning it off and on again?" wins again.

    Good point.
    In X86 builds, "local" is the suggested default domain suffix during the Debian OS setup. Since I'm peer-to-peer (no domain) I clear out the field.
    SBC's are built in another way where the default (local) is probably still in place.

    In any case, a domain suffix is another item that may or may not be supported by a consumer router. One way, or the other, it should work.

    We have FQDN and dedicated DNS for our environment.

    In the boxes of screenshot from @crashtest we have

    Hostname: omvhostname

    Doman name:

    The server address is \\

    But as I said, doesn't work.

    OMV is the only app/server we're having issues with.

    Thought someone here might know why or a trick to get it going... I'll keep troubleshooting it locally.

    by hostname I get error:

    "\\\SHARENAME is not accessible. You might not have permissions....."
    in same box..
    "Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. DIsuconnect all previous connectos the th server or shared resource and try again."

    by IP I get in.

    **I have been deleting connections in "net use" on the windows client between each test. By hostname of the OMV box it just doesn't work. 8|

    *** Of course there is a limitation of I think 16 chars max for groupname in debian to consider.

    Also I think a user can only be a member of 16 groups? That's a problem.

    True. But that doesn't mean that admin's have to leave the "users" group assigned to any shared folder. The selected group can be changed in the GUI. Further, any user can be removed from the users group, and added to other add-on group(s) of the admin's creation.
    There's flexibility in it. Setups can be as simple as using one group and one shared folder, or several of both.

    True, you could remove "users" as the owners group from the standard permissions, and change it to ..... hmm


    Which would give everyone the max access you define (i.e. rwx) to that share at standard level

    then, you could have to OMV level groups like:


    and use Access Rights Management > Shared Folder > PRIVILEGES to map the corresponding RO and RW access to those groups.

    Woohoo. If that works, I think that's exactly how I'll do it.

    So everyone is still getting put in "users" but "users" would not be used for any of our shares.


    Just remember that any user you add to your OMV server, will be added to OMV's "users" group by default. And, if the user created in OMV is identical to the username and password (cap's and all) that you're using to login to your client, you'll get transparent access to shares from that client.

    Not sure if you're pointing this out as a warning, but yes this is bad if a system admin is unaware:

    EVERY USER you create in OMV gets added to the linux system level group called "users"

    #cat /etc/group | grep users:

    So if you are create shares with "Extra options" including any type of "read" access for members of group "users", then it appears they will be able to read those files. Very bad in our case, where we are trying to figure out how to use OMV with private shares whose access can only be gained by membership to a group called sharename_RO or sharename_RW depending on if user needs read-only or read-and-write access. Unsuccessful so far.

    Take a look -> here . I you scroll up, in the same thread, there's a link to another explanation.

    Ok... problem is in your example imaged linked...

    If the share was a PRIVATE share (which all of our shares should be, until a user is given access) hen at the "standard" permission level (the green box)... Read/Write/Execute would for Group="Users" would give every OMV user full access to the share. Nevermind "Others" having Read/Execute. As I understand it, the GROUP "users" in OMV includes every single user created in OMV. Therefore, if in the greenbox you have anything other than "none" Group=users, then those users will be able to see and read private files.

    What I am asking is if there are any tutorials out there for OMV to set up simple READ-ONLY, READ-WRITE, NONE access to every share created in OMV based on membership to a correspondingly named group,

    i.e. if you are member of either group:


    Then you can see and have access to share name CONFIDENTIAL_SHARE.

    Otherwise you can not.

    I mean I can look at /etc/group and /etc/passwd and file permissions on linux, and kind of see what is happening, but I can not get it to function simply as I have described - because there are so many confusing permission levels and windows within OMV.

    Take a look -> here . I you scroll up, in the same thread, there's a link to another explanation.

    Thanks. I have used linux for many years. I understand linux level permissions of owner/group/other within the linux system itself.

    What is confusing is what OMV is doing on top of this.

    Specifically in the "Extra options" area, which again references "Owner" "Group" and "Others" *BUT* appears to affect something other than those same-named permissions on the system level. This can be confirmed when in "Extra Options" you set....

    Owner: root = rwx
    Group: users = None
    Others: none

    and replace + recursive.

    After it processes, everything on the actual file system is still chown root:users with mask like -rwxrws---+

    Where I would expect it to become -rwx------+


    So many layers of permissions. ?(

    We just want ALL top level shares to be private unless users are specifically given the the matching RO or RW group.



    We want:
    If you're a member of either the _RO or _RW group you can see the files in the corresponding share and interact with the share at your corresponding level of access. If you are not, you can't.

    Trying to wrap head around permissions in OMV....

    Our plan is 2 groups for each share will cover access:

    SHARENAME_ro gives read-only access
    SHARENAME_rw gives read-write access

    So imagine we have group names as such...


    We want to make it so if you are not a member of either of these groups, you will never see "SHARENAME",
    and if you are a member you will see it in WIndows environment and have the appropriate access level.


    So some questions about how to set this up

    when creating the new share in menu....

    Access Rights Management > Shared Folders:

    We create (+Add) share first with following for "permissions":

    Administrator: Read/write
    Users: Read/write
    Others: None

    NEXT... we click on [ACL] button....


    Here we have:

    In the "User/Group permissions" section...

    GRP_SHARENAME_RW [x] Read/Write
    GRP_SHARENAME_RO [x] Read-only

    (Everything else unchecked.)

    In the "Extra Options" section...

    Owner = root
    Permissions: read/write/execute

    Group = users
    Permissions: read/execute

    Others = none

    Is that correct?

    Also, specifically wondering, is there ever a situation where "Group" in ACL should be owned by group other than the group "user" ? Somehow I wound up with one share owned by group "root".

    Any solution to this?

    We are not (yet) using MS AD here -- for now, as first step testing, we are using local accounts on OMV. Testing so far includes admin and a single user with similar access management strategy of OP....


    sharename_rw allow read only
    sharename_rw allow read/write
    sharename_adm (in an AD environment would be used to manage permissions)

    We just ran into the same issue where some of the files and folders existing for our single test user have this "OWNER CREATOR" user, and the permissions in general are not consistent for different files/folders.

    Again, just a single test user and all files/folders have been uploaded or created by that user.

    "Use something else" can't be the correct solution. We have already had to take that approach after some issues with FreeNAS (haven't tried XigmaNAS or Nas4Free.... but both related by code-blood to FreeNAS? Anyway.)

    I have a share whose SMB access is based off of group membership.

    Membership to the group grants R/W access.

    I've removed a user from the group, but the user can still create files/folders within the share.

    The (test) user has window open to the share while I am making/applying the change by removing that user account from the RW group.

    As I understand it the user should no longer have access.