The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Network Scan permission error from MFP
deathnote666
Registered User regular
Registered User regular
I'm moving from a 2008 R2 to a 2012 R2 server. I have a Konica Minolta MFP setup to send SMB scanned items to a shared folder on the 2008 R2 server. I setup a folder with identical permissions on the 2012 R2 server but the MFP can't authenticate. I tried an admin's credentials in the MFP and they worked on the 2012 R2 folder.
When logged in as that user used for scan authentication on a workstation, they can access, create, modify, delete, etc. anything in that folder.
What am I missing?
Under share permissions, "everyone" can read/write along with the target user
Under security: everyone, domain users, and that user have read, write, modify, etc. permissions.
When logged in as that user used for scan authentication on a workstation, they can access, create, modify, delete, etc. anything in that folder.
What am I missing?
Under share permissions, "everyone" can read/write along with the target user
Under security: everyone, domain users, and that user have read, write, modify, etc. permissions.
0
Posts
Let me start by verifying that I understand the situation right. Does this accurately describe the situation?
the "no true scotch man" fallacy.
The 2008 R2 is a Domain controller and the 2012 R2 will be promoted to a Domain controller at a later time but is on the domain.
In other words, is it more like this:
A) \\server2012\scans
or more like this:
If it is more like (B), try giving the Konica's user Traverse Folder and List Folder permissions to crap, stuff, and butts.
the "no true scotch man" fallacy.
\\server2012\scans
On the MFP, you only need the \scans though.
You still need the server name. It just goes in a different field. I hope that's what you meant?
Here's what one of ours looks like (sanitized of course):
A few more weird Active Directory things that can cause inconsistencies in authentication:
If none of that works, then there are a few flaky things about Konicas that I've noticed...
In SMB Client Setting, there's an option for "SMB Authentication Setting." I've never gotten Kerberos to work reliably with the Konicas and ours are set to NTLMv 2. (You can try NTLMv1 if you want, but keep in mind that NTLMv1 is effectively insecure.) You could try Kerberos and see if the behavior changes.
We had problems with older versions of the firmware and passwords longer than 14 characters. (Windows uses a different hashing algorithm for passwords under 14 characters.) You could try temporarily setting a short simple password and see what happens. I know, if that were the problem it shouldn't work on either 2008 or 2012 but Windows authentication does weird things sometimes. And I definitely wouldn't leave it on a short stupid password, but it should be fine for troubleshooting purposes.
the "no true scotch man" fallacy.
Your first screenshot looks like mine. I do have the server IP in the one box and then the rest of the file path in the following box.
I'll check out what you said the next time I am there and will let you know what I find!