ReadyNAS Duo V2 SMB share rogue permissions in Windows 10

[bvbbvb]

RAIDiator 5.3.12

What I have couldn't be simpler: Unrestricted permission to the data from Windows clients. Settings:

Sharing protocols: SMB

Sharing access: all

Name:Everyone, read/write (2 other users as well)

Allow Anonymous Access checked

My understanding is that this should allow unrestricted access from Windows, however there are anomalies when using Windows 10 that don't appear in Windows 7:

1) PDF files created on the drive by a Xerox scanner throw "access denied" from Windows 10.

2) When xcopy-ing from the ReadyNAS (y:) to a local drive (f:), selected directories throw errors:

Access denied

Unable to create directory - f:\data\...

Any idea why WIndows 10 is having these problems with ReadyNAS?

[Retired_Member]

Did you modify anything in the file access permissions tab of the share in GUI of the NAS?

[bvbbvb]

Except for attempts troubleshoot this issue, the user settings haven't been changed since initial installation. Trying to open one of the PDF's in Windows 10, Adobe Reader says "You don't have permission to open this file". No entry appears in the ReadyNAS log. If there's anything specific you'd like me to try to generate log entries, please advise.

[Retired_Member]

---

@bvbbvb wrote:

Except for attempts troubleshoot this issue, the user settings haven't been changed since initial installation.

---

I'd start with resetting the file access permissions with the "reset" feature under the file access permissions tab.

[bvbbvb]

Thank you. That solved a large part of the problem. PDFs that formerly were "access denied" in Windows 10 are readable after "Reset Permissions". New scans stored on the drive by the Xerox printer are still inaccessible, though, from Windows 10.

How can I examine specific file permissions in detail to see what's different? How do I control the permissions assigned to newly created files? The "Files and Folders" settings for the share are; nobody, nogroup, read/write, read/write, read/write.

Creating the new, inaccessible file did not generate any log entries.