Samba and Privileges for share folder

  • Hi all,


    I'm newbie with OMV and have question regarding the Privileges option on already created Share folder. I've installed OVM (it seems version 0.1) for my banana pi:
    http://www.lemaker.org/resources/9-137/bananas.html


    Here si my scenario:
    1.Create share folder "Images" with permissions: Administrator (read/write), User (read only), Other (no access)
    2.Create share folder "Programs" with permissions: Administrator (read/write), User (read/write), Other (no access)
    3.Create new user metalpalo, user is automatically added to default group.
    4.Enable samba service and add mentioned share folders .
    5.From windows pc (logged as metalpalo) I can create folders in "Programs", in "Images" I don't - this I understand - standard linux permission logic
    6.On share "Images" click on "Privileges" button and tick Read/Write for my user "metalpalo"
    7.Click on Aplly button, my user is added into write list in smb.conf
    8.Try to create new folder under "Images" from windows, but NO permission to create directory - IS this correct?


    Now I have question: What is order of evaluation for linux permission, privileges and ACL. What has a high priority? By other words: Does samba service use my change via "Privileges" button.


    I've checked some links for privileges and ACL but I have still problem to understand this whole logic.


    If it should work, do you think that problems could be in version of OMV. Is here possible to execute update?


    Can somebody you explain me?


    thanks

  • It is because you gave read-only to users.
    When you create a new shared folder, leave the permissions as they are.
    You have to manage it with the privileges at the user level or group level.
    I am not an expert yet at how it works exactly, I'm new like you. From my experience, privileges > filesystem permissions. You have to see it like a funnel, one on top of the other. First it looks at the privileges and then at the filesystem permissions. For the privileges to work as intended when you tick and untick them, you have to leave the permissions to what they are when you create new shared folders. In your situation, like I said at above, you blocked write permissions to any user at the filesystem level, it means that even if you allow any user at the privileges level, he will still be denied to write. As for the ACL, see it like a way to give you more room at the filesystem level. It gives the possibility to add a groups and users to the basic filesystem permissions already allowed. Personally, the way I deal with it on my server is to create my shared folder with the default filesystem permissions, then create groups and filled them with users and set all their allowances with privileges by group. If someone feels like to correct me, I could be wrong, so do it if needed.


    Best of luck! :)

    • Offizieller Beitrag

    With samba you have to pass two levels. First samba perms (privileges) then standard posix permissions. This works by not changing the posix group other than users and leaving the permission for the group at read write, that's default omv. From your described procedure looks like you forgot to restart samba In the last case (images). A little trick, any changes you apply to share go straight to Smb.conf but that doesn't reload the daemon. Any changed in general samba and that restarts the daemon. ACL is an extension to posix sometimes they work sometimes don't. We recommend to stay only with privileges, ACL might be useful if you need more granular control.

  • thank you ZJohnAsZ

    If I good understand, the linux permissions are still controlled for users which successfully go through "Privileges" funnel. That means that "Privileges" don't override permissions, just help to speed filtering. Am I right?


    But in this case it doesn't matter either I tick "Read/write" and keep alls unchecked. From my point of view, checked "Read/Write" doesn't filter anything.

  • If I good understand, the linux permissions are still controlled for users which successfully go through "Privileges" funnel. That means that "Privileges" don't override permissions, just help to speed filtering. Am I right?


    Well, yes


    From my point of view, checked "Read/Write" doesn't filter anything.


    It changes something depending on what permissions you gave when you created your shared folder.
    When you create a shared folder you have the permissions: Administrator=(root): read/write, Users=(all the users you will create with OMV): read/write, Other: read-only.
    In your case, you kept any user in your OMV to write in that particular shared folder because you gave read-only to users.
    Instead, give the group Users read/write permissions and create 2 new groups: admins and members for exemple. Add your metal palo user to the admins group and then you could not tick anything or tick read/write.
    To the members group you can allow read-only. If you add users to it, they won't be able to write. At the base, it is like giving all permissions to all users, but you restrict them with privileges.

  • I'll try to restart manually. But now I'm not sure what is right. I answer from ZJohnAsZ collided with your one? Or both ansewr are correct?


    Click on Aplly button, my user is added into write list in smb.conf


    I missed that part, but, subzero will correct me if I'm wrong, I think that even if you add the user to the write list using samba extras, if you denied it write permissions at the filesystem level, it won't work.

  • ACL is an extension to posix sometimes they work sometimes don't. We recommend to stay only with privileges, ACL might be useful if you need more granular control.


    If you allow my little hijack, if someone initially altered ACL, how he could completely reset all permissions in said volume/disk to start from scratch?
    As I've experienced, ACL will always deform permissions when you leave using them. Perhaps the OP also has this problem.


    Perhaps he needs to issue a setfacl -bR ?

    • Offizieller Beitrag


    I missed that part, but, subzero will correct me if I'm wrong, I think that even if you add the user to the write list using samba extras, if you denied it write permissions at the filesystem level, it won't work.


    Yes if you alter the group permissions let's say the first posix level (not ACL), ownership or read only, it won't pass. No matter what privileges you set.


    You can test this in real time. First set a clean new share(not ACL please), give privileges read-write. Mount the share in windows check you can read write then fill it with some rubbish.
    Through ssh go to the shared folder in the filesystem. Start changing the permissions sequentially with chmod to the group in the shared folder (chmod 775 -R share/), first 6 (the execution bit is irrelevant), you can write delete. Then change to 4, you won't be able to delete but you will see everything. Then set to 0 they will all disappear from the mounted drive


    Code
    chmod 775 -R share/
    chmod 765 -R share/ #this is the same as before
    chmod 745 -R share/ # read only
    chmod 705 -R share/ #no reading at all


    Regarding this, I am at the end of a guide that is intended to explain once and for all the OMV simplified privilege schema. I have it in word, and i need to move it to BBCODE

Jetzt mitmachen!

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