Windows cannot to access to shared folder

    Hello,

    I'm having an issue with the access control list (ACL) for some shared folders. There's a problem with one folder in particular, while the others, set up the same way, are fine. Users of this one shared folder sometimes get a message that says "Windows cannot access \\path to the network share. You do not have permission to access..." When I log in as an admin in the OMV GUI and go to shared folders -> select the folder with the issue -> ACL -> and I click Apply to reload the permissions, it starts working again. This problem isn't just on one computer. Even when I connect to this folder from a different computer using the same account, the problem comes back until I reload the ACL permissions again. What's odd is that other folders set up the same way don't have this issue.

    Any ideas what the issue can be?

    No need for ACL at all. I would reset it all and the the below.


    Thread
    [HOW-TO] Connect to OMV SMB shares with Windows 11
    1. We need to create a user. In OMV goto Users >> Users >> Plus symbol and than click create.

    forum.openmediavault.org/wsc/index.php?attachment/32152/

    Add a user and password (as an example I will use User BlueCoffeeand password 12345) than hit save and apply the settings at the top

    2. Now we need to make a shared folder in OMV so go to Storage >> Shared Folders and click the plus symbol again

    forum.openmediavault.org/wsc/index.php?attachment/32153/

    I am going to name the folder Media in this…
    BlueCoffee


    edit = you you still on omv5? update if so.

    BlueCoffee The OP may have posted a screenshot which shows an ACL tab in OMV5, but it doesn't necessarily mean ACLs have been used, you can't tell from the screenshot.


    virtIT The odd thing in your screenshot is whatever the directory it points to , the "Extra Options" show both the group "users" and "others" have no access. Was the screenshot taken before or after you re-applied permission? What filesystem have you used on your data drives? Are connecting to shares from Windows, or MAC, or Linux? Are you able to connect to your OMV5 via ssh?

    Quote from BlueCoffee

    was just going by this part. "I'm having an issue with the access control list (ACL) for some shared folders."

    Unfortunately many users refer to this section/tab of OMV, or even use the term ACL, when they in fact are just using standard linux perms.


    I believe past discussions have taken place about a re-design of the WebUI to separate changing std perms from setting and modifying ACLs.

    Quote from Krisbee

    BlueCoffee The OP may have posted a screenshot which shows an ACL tab in OMV5, but it doesn't necessarily mean ACLs have been used, you can't tell from the screenshot.


    virtIT The odd thing in your screenshot is whatever the directory it points to , the "Extra Options" show both the group "users" and "others" have no access. Was the screenshot taken before or after you re-applied permission? What filesystem have you used on your data drives? Are connecting to shares from Windows, or MAC, or Linux? Are you able to connect to your OMV5 via ssh?

    In the picture, permissions settings are not visible because I don't want to display user accounts or groups. Users are added to groups, to which permissions are later assigned in the ACL list for specific network shares.

    The timing of taking the screenshot doesn't matter in my case because when I mention 'refreshing permissions,' I simply mean opening the ACL list, going to the relevant subfolder with the issue, and clicking Apply. This usually solves the problem for some time.

    The file system used on the data storage disk is ext4.

    Yes, I have SSH access to OMV5.
    We are using Windows 10.

    Quote from virtIT

    In the picture, permissions settings are not visible because I don't want to display user accounts or groups. Users are added to groups, to which permissions are later assigned in the ACL list for specific network shares.

    The timing of taking the screenshot doesn't matter in my case because when I mention 'refreshing permissions,' I simply mean opening the ACL list, going to the relevant subfolder with the issue, and clicking Apply. This usually solves the problem for some time.

    The file system used on the data storage disk is ext4.

    Yes, I have SSH access to OMV5.
    We are using Windows 10.


    Well it seems you really are using ACLs in OMV. Without seeing detailed info which would break your confidentiality, the only thing I can guess at is that clickling "APPLY" is (re)setting a default ACL on a shared folder. You need to examine the output of the "getfacl" command on the relevant shared folder at the OMV CLI. Additionally, re-examine your SMB/CIFS share config via WebUI or by using "testparm -s" at the OMV CLI.

    @virIt Probably should have mentioned for completeness that, as I'm sure you know, because Linux is only posix.1e ACL letting users twiddle permissions via file property security tab in Windows can cause problems.

    Quote from Krisbee

    Well it seems you really are using ACLs in OMV. Without seeing detailed info which would break your confidentiality, the only thing I can guess at is that clickling "APPLY" is (re)setting a default ACL on a shared folder. You need to examine the output of the "getfacl" command on the relevant shared folder at the OMV CLI. Additionally, re-examine your SMB/CIFS share config via WebUI or by using "testparm -s" at the OMV CLI.

    Attached are the results of the getfacl command on the parent directory 'P_0046_R&D_QT_2A_1' and one of the subdirectories, FOTO, which occasionally has issues. The FOTO directory was created by a user other than root, most likely because the user a... created this directory.

    Also attached is the result of the testparm -s command. The configuration for the MECH_Files network share looks identical to that of the other shares, which do not have any problems.

    Did you list the perms on /nas/MECH_FILES/ ? I don't remember the paths used in OMV5 for mount points. Nothing jumps out - but then I don't do this stuff for a living. I seem to remember SAMBA recommends using "map acl inherit = yes" in this kind of smb share config. Going back to your first post, the "sometimes" error comment chimes with having to hit "apply", if hitting the "apply" triggers a restart of the smb server. Monitoring journalctl -f would tell you that. I don't have any other suggestion.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login