This isn't Jamf-specific, but I'm hoping someone here might be able to shed some light on the issue:
If a user mounts an SMB share and attempts to copy a file to a folder on the share with "Write only (Drop Box)" permissions, i.e. -wx permissions, the Finder first (correctly) warns them that they can "put items into" the folder, but they "won't be able to see them". But after clicking OK, the file is not copied, and a dialog box appears with this error: "The operation can't be completed because you don't have permission to access some of the items."
The clients are running macOS 10.13.6 and the server hosting the share is running macOS 10.13.5.
I've searched online for settings in these SMB configuration files on the server that might make a difference, but haven't found any:
Some users reported that they can fix this error for Macs connecting to non-Apple SMB servers by adding the line "unix extensions=off" to the smb.conf file on their server, but Apple's implementation of SMB appears to be non-standard, so this doesn't seem to be an option.
After a lot of trial and error, I suspect that this is simply a bug in Apple's current implementation of SMB. Can any colleagues out there with more than one Mac on their network running macOS 10.13.6 try to copy a file to another user's ~/Public/Drop Box folder on another Mac on their network to confirm that they see the same error on their server?
from the information provided, I take it this is over an internal network. If external, SMB is probably blocked and if being blocked internally, could it possibly be going over a firewall? SMB is pretty locked down....
I just ran into this myself this last week when a call came in from a professor in one of our largest Mac classrooms in a bit of a panic. I went through a very similar troubleshooting/triaging procedure as @srhyne but I have not found anything myself yet, either.
Thought I'd bump this and see if anyone shakes loose any new insights...
I would add that the classroom Macs are all bound to AD, and when connecting to the share via SMB automatically authenticates (guest off, I assume using Kerberos tickets).
Additionally, if I modify the permissions of the 'Drop Box' folder, for example
chmod g+r Drop Box then it works, but is "broken" (not a blind drop box anymore).
(Using AFP did not work in that lab, I assume because the Guest user is disabled. Attempt to authenticate using AD creds when prompted did not work.)
So far altering the unix file permissions worked, but "broke" the Drop Box aspect. I have tried Access Control List but they did not appear to have any particular effect insofar as working around the apparent permissions issue.