Cannot access ACL for new shared folder

1. offizieller Beitrag

    Hi everyone

    I know this problem (or one much like it) has been encountered by others - because I've already read several posts about it & no obvious solutions have emerged.


    I've just finished a brand new OMV install, at the end of which I added a new 10Tb WD drive (USB connection into RPi4). I have created and mounted a 6Tb partition (NTFS), but cannot access its ACL configuration - the ACL button is grayed out.


    Some additional details to inform replies / suggestions:

    1. This file system is not yet referenced (as attached screenie shows, there is no check mark there); configuring its ACL is, 100% literally, the first operation I have attempted to perform on it.
    2. I have given the relevant user read/write perms in shared folder permissions.
    3. The reason I rebuilt my whole system is because I encountered exactly this problem with my previous OMV setup - so I figured (wrongly) the quickest way to work around it was a "scorched earth" rebuild.
    4. I have also created a couple of smaller partitions (1 Tb or less) with Ext4 file systems and been able to configure their shared folder ACLs exactly as expected.

    I don't really have a usable system if I can't control access to the main data partition & would be delighted if someone could explain the problem to me and beyond grateful for a workaround (e.g. manually adding something in config.xml?).


    Cheers


    Neil

  • votdev

    Hat das Label gelöst hinzugefügt.

  • votdev

    Hat das Label OMV 6.x hinzugefügt.
    • Offizieller Beitrag

    I can't answer your question because I don't know the answer. But may I ask why do you need ACL permissions?

    Zitat von synapsensau

    NTFS is a file system from the Windows world and therefore cannot handle the Linux ACL. Use a Linux file system (ext4, btrfs, xfs.....) so that the Linux ACL takes effect again.


    Is possible to use NTFS drives?

    Thanks for your stunningly simple & completely logical response.


    Duh... that should've been obvious to me, so I'm a bit embarrassed. 😲 (I blame it on my Windows upbringing.)


    Until it died a few weeks ago, the main partition on my previous NAS drive was absolutely NTFS. But it has been a few years since I set that up, so I must conclude that I never had access to the ACL config for it - which wasn't a problem... until I had to set up the replacement drive recently.


    Now I guess I'll discover how much I don't know about the Linux ACL! :/


    Cheers


    Neil

    • Offizieller Beitrag
    Zitat von stinkycheese

    For granular control over who can access what, and how.

    In the vast majority of cases it can be resolved with the standard linux permissions. I would try to stick to that.

    I have never needed ACL, I have always been able to solve all situations. ACL is an unnecessary headache.

    Zitat von chente

    In the vast majority of cases it can be resolved with the standard linux permissions. I would try to stick to that.

    I have never needed ACL, I have always been able to solve all situations. ACL is an unnecessary headache.

    Thanks for your insight on this, chente - as I mentioned, Windows is how I was "brought up".


    But now that I'm rebuilding my system, it's probably a great time for me to expand my skills. And I LOVE simplicity.


    Perhaps you could give me a tiny kickstart with a simple (I hope!) example. 🤞


    Let's say I have an Ext4 FS that will only be accessed as an SMB share through Windows as follows:

    • User A needs Read/Write/Execute access.
    • User B needs Read access.
    • User C has no access.

    (SMB is my go-to share format for this Windows-only (family) environment - but I'd be happy to hear any suggestions you may have for something different that OMV supports.)


    I know how to do this via ACL, but I don't have any experience using permissions only.


    With a bit of a steer, I should be able to figure the rest out solo!


    Thanks very much for your help


    Neil

    • Offizieller Beitrag
    Zitat von stinkycheese

    Let's say I have an Ext4 FS that will only be accessed as an SMB share through Windows as follows:

    User A needs Read/Write/Execute access.
    User B needs Read access.
    User C has no access.

    That's very easy. Now I don't have time to give a long answer. In a while I'll explain how to do it.

    In the meantime you can read this, maybe it will help you. https://wiki.omv-extras.org/do…misc_docs:nas_permissions

    • Offizieller Beitrag

    My long answer.


    There are three levels of permissions, each more restrictive than the last. If you ban something on Level 1 it won't matter what you do on Levels 2 and 3, they won't accomplish anything.



    Level 1.


    Linux file and folder permissions. Basically it allows you to define:

    - An owner user. By default in OMV it is root.

    - An owner group. By default in OMV it is users.

    - Owner user read write and execute permissions. By default in OMV all three are allowed: reading, writing and execution.

    - Permissions to read, write and execute the owner group. By default in OMV all three are allowed: reading, writing and execution.

    - Permissions to read, write and execute the rest of the users (anyone). By default in OMV reading and execution is allowed, not writing.


    If you access any file, if you have not modified it you will see the permissions: root users 775



    Level 2.


    Shared folder permissions. (actually samba has something to do with it, but let's keep it simple, let's forget that). The permissions you set at this level can restrict the permissions set at Level 1, but can never extend them.


    In each shared folder created in the OMV GUI you can define read, write and execute permissions for each user you have created in the OMV GUI (attention, this solves your problem).



    Level 3.


    Service permissions, samba in this case, could be another service. The permissions you define at this level will restrict the permissions granted in Levels 1 and 2, but can never extend them. If at level 1 or 2 you prevent everyone from reading, samba won't be able to do anything against it.


    With samba shared folders in the OMV GUI you can define if that folder is read-only (everyone) or write-only (everyone) or public.


    _______________________________________________________________________


    How to solve your case. I think it has been explained, it is clear that Level 2 is what you need.


    How to do it.


    Level 1. First make sure that Level 1 does not restrict anything to the other levels, that is, standard OMV permissions. For that the plugin openmediavault-resetperms is useful. Here is a guide to use it. [How-to] Use the openmediavault-resetperms plugin


    Level 2. Once the above is done, go in the OMV GUI to Storage>Shared Folders. Select your shared folder and click Permissions. In the window you will see that you can define read/write/execute permissions for user A, read permissions for user B, and no permissions for user C. Accept.


    Level 3. Go to Services>SMB/CIFS Select your shared folder with samba and click edit. The standard configuration of OMV is what you need. Make sure Read only is unchecked. Only Browseable and Hide dot files are checked. You accept.


    A bonus here, you can add an extra configuration in the last field, Extra options. If you add access based share enum = yes user C will not see the shared folder in his file manager because he does not have access. Only users with access will show the folder.


    ________________________________________________________________________________


    Your problem is solved. With this explanation you can solve the vast majority, if not all, possible situations. You don't need ACL permissions. You could have complications with nested folders (one shared folder inside another), it can still be solved but if you can avoid them better.


    If all this does not solve your needs, you still have the linux ACL permissions, but you must learn to use them, they do not work in the same way as the windows permissions. 99.9% of users do not need them.

    Thanks very much - it is so kind & helpful of you to take the time to explain this better way of doing things. This is a terrific community to be a part of. :)


    I'll be spending my Saturday afternoon experimenting with your suggested approach.


    I am most grateful!!!


    Neil

    • Offizieller Beitrag

    I'm not sure I'd argue permissions are better.. it's just to many here use ACL's improperly. I've used ACL for years and never had a single issue.

    • Offizieller Beitrag
    Zitat von stinkycheese

    I'll be spending my Saturday afternoon experimenting with your suggested approach.


    I am most grateful!!!

    Happy to help.

    When you do it you will see that it is much easier to do it than to explain it. You'll be done in 5 minutes.

    And, as I said, using ACL permissions doesn't make any sense if it's not a very special case. You don't need them, you'll just make your server more complicated for no reason.

    Zitat von chente

    Happy to help.

    When you do it you will see that it is much easier to do it than to explain it. You'll be done in 5 minutes.

    And, as I said, using ACL permissions doesn't make any sense if it's not a very special case. You don't need them, you'll just make your server more complicated for no reason.

    WOW!!!!!


    Everything you said was absolutely on the money, Chente. Once I understood the basic principles from your explanation, it took me less than 5 minutes to configure my shares exactly as I needed, without the use of ACL or Samba options (with the exception of disabling "browseable" for one specific share).


    In any other situation, I'd say it was embarrassingly simple & that I had wasted quite a few hours "barking up the wrong tree" - but there's nothing embarrassing about learning how to make anything simpler!


    Thanks again for your guidance - I am very grateful for it & the time you put into it.


    Warmest regards


    Neil

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden