Connecting to linux share from Windows - error

Have a workstation trying to connect to a linux share and receiving an error.  Mapping to a Windows share - no issue.  When the Windows 10 machine (Surface Pro 4) maps to a Linux share, receive the following error message:

\\IP is not accessible.  You might not have permission to use this network resource.  Contact the administrator of this server to find out if you have access permissions.

A Specified logon session does not exist.  It may already have been terminated.

No problem for 100 other machines to connect to it, just the surface.  I have changed some security sessions to no resolution.  when trying to connect to \\IP address, it does not even show any shares on that server..
odddballAsked:
Who is Participating?
 
odddballConnect With a Mentor Author Commented:
Thank you for the assistance.  Unfortunately they did not help.  In the end, looks like a Windows 10 update caused the issue.  Used the restore point and the issue went away.  Thank you for all your help.
0
 
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
From a first glance, I would say this is a LINUX permissions issue.

When you're running SAMBA, you allow Windows-based client systems to connect to your LINUX system. There is a username associated with the connection (sometimes a LINUX user, sometimes an AD user -- if the LINUX system has been joined to an AD).

THAT username must have share permissions in SAMBA, but then must also have access permissions in LINUX.

SO, by way of example, lets say the username you're connecting to is 'MYAD\expert' (and the LINUX system is successfully joined to the MYAD domain). Let's also say the share, as defined in SAMBA, is called 'PUBLIC' and the location of that share on the LINUX system is '/home/public'.
 - If SAMBA does not list 'MYAD\expert' as an allowed user in the share definition, the connection will be refused by SAMBA
 - if the folders / and /home don't have at least EXECUTE permission for the user 'MYAD\expert', then the share will be unreachable and the connection will be refused by SAMBA
 - if the /home/public folder has ONLY EXECUTE permission for the user 'BYAD\expert', you will be able to connect, but will NOT be able to see anything in the share. (However, if you KNOW the name of the file/folder in the share, AND you have permissions to it, you CAN actually access it!)
 - ONLY if all these above tests pass, AND the user 'MYAD\expert' has READ AND EXECUTE permission on /home/public -- ONLY THEN will the share work properly.

So again, you appear to need to check the credentials being sent to the LINUX/SAMBA system, and check both the SAMBA SHARE permissions AND the LINUX file/folder permissions to resolve this issue.

I hope this helps!

Dan
IT4SOHO
0
 
ZENandEmailguyCommented:
Allow me to throw two wild guesses into the air for you:

1) Does the surface have the Windows firewall on?  If so, as a test, can you disable it or whatever firewall is in use to see if a connection is successful?

2) What authentication method does the Surface use by default?  (Kerberos, NTLMv2, NTLMv1).  I recently encountered a situation where a firewall would not join a Windows 2012r2 DC to provide SSO authentication because the DC didn't allow both NTLMv1 and NTLMv2...it allowed only Kerberos by default.  A simple registry update allowed what our firewall required.

Perhaps these will take you in a positive direction.

Scott
0
Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

 
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
Zen makes a couple of good points, but I think its important to make a counter-point.

A) The Surface might be being blocked by its own firewall -- it must "trust" the connection that it is using to connect to the Linux system (be a PRIVATE connection, not a PUBLIC one).

2) The Surface NEED NOT be joined to the AD domain to connect to the Linux share -- however, if it IS joined, then the credentials on the AD will be used to make the connection and that takes us back to the LINUX permissions. If the Surface is NOT joined, but you are using an AD set of credentials, you MUST include the AD name in the credentials provided. (E.g.: the username in my example is  'MYAD\expert' -- NOT just plain 'expert'.


Dan
IT4SOHO
0
 
ZENandEmailguyCommented:
Dan,
I agree on both of your points.  

I have a CentOS 5.4 (its a bit old) box that I needed to connect a Windows 7 Pro laptop to recently.  I installed Samba onto and created my user account both with the useradd command, putting it into the /etc/passwd file and with the smbpasswd command.  I don't recall assigning any specific permissions to the linux file system, nor putting the user account into sudo or a full-access group (root).  Once done I can enter the following into a CMD prompt:

net use r: \\CentOS-IP\backups /user:scott and it connects

Scott
0
 
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
You definitely DO NOT want to have a 'samba' user as a SUDOER -- but that being said, Samba has no way to exploit the added permissions to such a user in any case!

If your share definition and user add (more appropriately, smbpasswd user add) allowed you to browse with no further action, then the permissions (likely for ALL) were already present. Common, but you cannot RELY on that fact. Whats more, there are potential ACLs that can play havoc with permissions.

Dan
IT4SOHO
0
 
odddballAuthor Commented:
Windows 10 update issue
0
 
odddballAuthor Commented:
Windows 10 update
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.