Hide Shares from Users

Zitat von paulouk

I have various shares set up but some users only have access to some shares. Is there a way to hide shares that they don't have access to as currently they can see but dont have access to them

If you use samba to share those resources yes. There is a way:

In the OMV GUI go to Services>SMB/CIFS>Shares, select the folder and press the Edit button. In the Extra options field add the following text:

access based share enum = yes

Press Save.

From now on that folder will only be shown to users who have read or write permissions.

Zitat von chente

If you use samba to share those resources yes. There is a way:

In the OMV GUI go to Services>SMB/CIFS>Shares, select the folder and press the Edit button. In the Extra options field add the following text:

access based share enum = yes

Press Save.

From now on that folder will only be shown to users who have read or write permissions.

While this works, the issue he's going to likely run into.. is by default, all users created in the webui, are in the "users" group, and shared folders created in the webUI, by default give "users" read/write permission.

To me, rather than dealing with SMB options.. if done PROPERLY.. ACL is how I would deal with this. Create control groups for the folders, and users that should have access to those shares,. The key word of course, is properly.

See post 15-17. I broke it down there.

Thema

How to config the subfolder permission under SMB

Hi all,

Could anyone give me hints how to config sub-folders permission under the main-folder of SMB ?

I created the shared folder name as "Documents".
Under the folder "Doucments", there are three sub-folders such as "DataA", "DataB" and "DataC".

Meanwhile, I created 3 users for accessing (read and write) their sub-folders only.
Users: A, B and C

So, the paths of SMB share might be:
/Docucments/DataA/ <-- only user A can access.
/Docucments/DataB/ <-- only user B can access.
/Docucments/DataC/ …

lee.tom

13. Dezember 2022

Zitat von KM0201

While this works, the issue he's going to likely run into.. is by default, all users created in the webui, are in the "users" group, and shared folders created in the webUI, by default give "users" read/write permission.

Actually this problem does not exist. OMV assigns the folders to the root owner and the users group, effectively. And the standard permissions (unless they are modified when creating the shared folder) are 775, that is, at the file permissions level, as you say, the users group would have access to that folder, that is, all users.

BUT, when you then define the permissions in the OMV GUI for each user, what you are doing is defining the permissions in the upper layer of samba. This layer restricts existing permissions at the file level, so if you don't give a user read/write permissions on a shared folder, that user won't be able to modify that folder if they access it via samba, of course. Then you just have to adjust the permissions correctly for each user so that everything works normally. So you just need to deny or allow access to any user so they can access a folder, even if that user is in the user group and the permissions are 775 the samba restricted permissions will prevail.

The settings I provided to add to the Extra options field are based on permissions from the top layer at the samba level, not the bottom layer at the file level, so it works without any issues. It has been working on my server this way for a long time. I don't need to set ACL permissions. I just add that command on each shared folder and each user can only see the folders they have assigned access permissions to in the GUI.

On the other hand, I do not doubt that the method you propose using ACL permissions works, I am convinced that you have tried it. It's good to know there's another way, I didn't know about it, thanks.

So I guess each user will have to choose their path based on their particular needs and use case.

In either case, modifying ACL permissions is modifying permissions at the file level. I personally prefer not to touch file-level permissions unless it's necessary for some reason, and so far I've never needed to. All my shared folders are still with the permissions set by OMV, the owner is root, the owner group is users and the permissions are 775. And everything works perfectly with a few clicks in the GUI.

I just edited my last post because I realized something that I didn't know. I thought that users had restricted permissions in samba by default but I just checked in a vm that they don't. You are right that users can access by default through samba, I thought this was not the case. Then all you have to do is restrict the permissions of each user to make sure they can't access the shares if necessary. In any case it still works correctly if the permissions are set correctly in the GUI.

Oops, now I'm not sure about the behavior of samba's default permissions. I keep trying and sometimes it gives me access and other times it doesn't.

In either case restricting the permissions in the GUI ensures that a user cannot access a shared folder.

Zitat von chente

Oops, now I'm not sure about the behavior of samba's default permissions. I keep trying and sometimes it gives me access and other times it doesn't.

In either case restricting the permissions in the GUI ensures that a user cannot access a shared folder.

This is exactly why I prefer using control groups for permissions, rather than user. As you saw, by default, all users will have r/w if you don't change the users group permissions.

By using groups as I suggested.. you can easily allow/revoke permissions by simply adding/removing them to the appropriate group.

Zitat von KM0201

This is exactly why I prefer using control groups for permissions, rather than user. As you saw, by default, all users will have r/w if you don't change the users group permissions.

By using groups as I suggested.. you can easily allow/revoke permissions by simply adding/removing them to the appropriate group.

Samba permissions have nothing to do with file level permissions. The first permissions layer is the file permissions layer. The second layer of permissions is the samba permissions layer. It is a layer that is applied on top of file-level permissions and can only further restrict permissions, never expand. So if samba-level permissions are enough, you don't need to set file-level permissions. In some cases it may be necessary, depending on the particular configuration.

Actually all this is not related to the OP's request of this thread. Reading a bit the thread you linked, I see that the case treated there is different from what is being asked here. What the OP is asking for is to hide the shared folders from users without permissions. And that can only be solved with the command that I posted in post #2.

As for the case discussed in the other thread, it is different, there it was intended to restrict permissions on subfolders, but the subfolders will continue to be shown to users without permissions unless you do something else, like the configuration I said in samba.

_________________________________________________________________________________________

Regarding the solution that you applied there, I think you solved it well by looking at the options that the OMV GUI allows, but I think that it could still be improved a bit if the OMV GUI had other permission management options. The difficulty here is that the OMV GUI doesn't allow you to modify only native permissions, it does it the other way, it does a mix of both and forces you to apply ACLs as well. Let's see it with the example you gave.

What you did in the GUI in post #15 with the jane subfolder is change the owning group to jane, that results in this once applied:

root@omv-pruebas:/srv/mergerfs/pool/documents# getfacl jane
# file: jane
# owner: root
# group: jane
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---

If you notice the owner group at the file level (POSIX) has changed to jane, this is not done by the ACL permissions, it is done directly with POSIX. But the last three default lines also appear, this is done by the ACL permissions extension and will cause files and folders within this directory to inherit the properties of the parent directory.

This last part related to inheritance could be useful... if it worked... Actually this on Windows doesn't work at all, any file created will be owned by the user who created it, not root (in this case root is the owner of the parent folder) and likewise the permissions are nothing like those of the parent folder either. So this is useless and all it does is add ACL configurations that are not needed. Therefore the ACL permissions part could be omitted.

What the GUI is doing is equivalent to this if done in the CLI:

root@omv-pruebas:/srv/mergerfs/pool/documents# setfacl -Rdm g::rwx jane/
root@omv-pruebas:/srv/mergerfs/pool/documents# getfacl jane
# file: jane
# owner: root
# group: users
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---

root@omv-pruebas:/srv/mergerfs/pool/documents# chown -R :jane jane
root@omv-pruebas:/srv/mergerfs/pool/documents# getfacl jane
# file: jane
# owner: root
# group: jane
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---

If you applied the command assigning the owner group with ACL permissions you would get another result, that's not what OMV does.

So if we didn't want to apply ACL at all we can get the same result by just applying the owning group with native permissions, starting from scratch this would suffice:

root@omv-pruebas:/srv/mergerfs/pool/documents# chown -R :jane jane
root@omv-pruebas:/srv/mergerfs/pool/documents# getfacl jane
# file: jane
# owner: root
# group: jane
# flags: -s-
user::rwx
group::rwx
other::---

We have not applied ACL permissions at all. The owner group is jane so the operation will be the same.

Only users in the jane group will be able to access the /jane directory and the configuration will work the same way as in your proposal using ACL permissions. The downside is that the OMV GUI doesn't allow you to do this and you need to do it in the CLI to avoid using ACL permissions.

I'm to tired to read all that, but.. I never said ACL was the only way, just my matter of preference. It clearly works and is very easy to setup/manage.

Of course, the GUI does not allow you to assign owners in any other way. It's a shame.