OMV 7 New folders from the user "guest"

  • I'll put it in this category, I'm not sure.

    All folders were ready with OMV 4-5 versions, hands reached to update everything. I installed OMV 6, and immediately updated it to OMV 7.

    It took some changes, a new folder is being created from the Linux client with "guest" rights, but there is no way to move something to it "access denied".

    I checked all the settings, everything is as it was before. If you make a "Storage - Shared Folders - ACL" with the "Replace" "Recursive" checkboxes, everyone has access.

    I checked the permissions for the new folders of her "nobody". I created a completely new shared folder for the test, tried with different settings with active and inactive "Inherit ACLs" "Inherit permissions" there are no changes, the Linux client can only create a new folder in the shared folder, but nothing can be created in it "access denied". The Windows client can create new folders and attachments.


    The access solution for the "guest" is only to allow in the "Storage - Shared Folders - ACL" settings to allow reading and writing for the "nobody" user.


    Is this how it should be?

  • VikFx

    Hat das Label gelöst entfernt.
  • The access solution for the "guest" is only to allow in the "Storage - Shared Folders - ACL" settings to allow reading and writing for the "nobody" user.

    TBH, I don't use "guest" access on shares. Just to re-iterate what you already probably know, in Linux the "guest" user equates to "nobody:nogroup".


    You didn't mention whether the SMB/CIFS share is set with "guest only" or "guest allowed". Do you really mean you needed to set an ACL on the folder, or did you just use that ACL tab to change the standard Linux perms from "root:users:others" to something else? I would've expect setting perms as 777 so the "nobody" user is treated as "other" when determining access ought to be enough.


    .... the Linux client can only create a new folder in the shared folder, but nothing can be created in it "access denied". The Windows client can create new folders and attachments.


    I found the same behaviour accessing a "guest allowed" SMB share via kde Dolphin. At the first level in the shared folder you can work normally, but not a level 2. Why has access to a sub-folder become read only?


    My example on the OMV server:


    Code
    root@omvtest:/srv/dev-disk-by-uuid-e08eb6e6-e84b-4845-848a-bdceb1b9d9c1/forguests# ls -ld
    
    drwxrwsrwx 3 root users 4096 Jan 10 11:52 .
    
    root@omvtest:/srv/dev-disk-by-uuid-e08eb6e6-e84b-4845-848a-bdceb1b9d9c1/forguests# ls -l
    total 108916
    drwxrwsr-x 2 nobody users      4096 Jan 10 10:59 gfolder
    -rw-rw-rw- 1 nobody users 111524686 May 16  2014 test2.flac
    root@omvtest:/srv/dev-disk-by-uuid-e08eb6e6-e84b-4845-848a-bdceb1b9d9c1/forguests#


    The reason in my case is that the filemanager "dolphin" cannot be accessing the "gfolder" as "nobody".

    Turn on "inherit permissions" in the SMB share and things change. Create new sub-folder, golder2, and now its world-writeable:



    In summary: set perms on shared folder to 777 and turn "inherit permissions" when create your SMB share. I would advise against using an ACL.

  • Zitat von Krisbee

    TBH, I don't use "guest" access on shares. Just to re-iterate what you already probably know, in Linux the "guest" user equates to "nobody:nogroup".

    Yes, but this did not limit the use of shared resources in OMV 4/OMV 5.



    You didn't mention whether the SMB/CIFS share is set with "guest only" or "guest allowed". Do you really mean you needed to set an ACL on the folder, or did you just use that ACL tab to change the standard Linux perms from "root:users:others" to something else? I would've expect setting perms as 777 so the "nobody" user is treated as "other" when determining access ought to be enough.

    For those resources where everyone is allowed access, "guest allowed" is set.



    I found the same behaviour accessing a "guest allowed" SMB share via kde Dolphin. At the first level in the shared folder you can work normally, but not a level 2. Why has access to a sub-folder become read only?

    That's the question I asked.


    Now I have once again created a new shared resource for the test with the "guest allowed" parameters. It works correctly, everyone has access to the first level and attachments.

    But on the Linux client, I updated the Samba client to a new version.

  • VikFx

    Hat das Label gelöst hinzugefügt.

Jetzt mitmachen!

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