• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 36
  • Last Modified:

Cannot Access File Share

RPC-Error.jpg
Hi all,

When we access file share between one server i get this error. There is Sonicwall firewall between two sites, we allowed the any to any between both servers.

Any idea ?
0
ucguy
Asked:
ucguy
  • 8
  • 4
  • 2
  • +2
1 Solution
 
David Johnson, CD, MVPOwnerCommented:
there must be a two way trust if they are different domains. i.e. nyc.example.com lv.example.com
0
 
ucguyAuthor Commented:
Nope. This is same domain.
0
 
AbhishekJhaCommented:
Try running this command first &  then try accessing the shared folder.

net use \\192.168.1.31\sharedfoldername  /user:domain\user id & hit enter. It will ask for the password of mentioned user.

If above works then try accessing the UNC path.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
ucguyAuthor Commented:
I have tried the share like this.

\\192.168.1.31\Sharename. its working.

if I run it like \\192.168.1.31 will not working.

I think \\192.168.1.31\IP$ not working

any idea ?
0
 
David Johnson, CD, MVPOwnerCommented:
if you want the c: directory \\192.168.1.31\c$
 \\192.168.1.31\IP$ isn't a valid share were you thinking instead of \IPCS$
0
 
ucguyAuthor Commented:
that also cannot access
0
 
David Johnson, CD, MVPOwnerCommented:
on the server in a command prompt type "net share" this will tell you the available shares.
0
 
ucguyAuthor Commented:
I think its rpc problem there may be MTU problem.

Can we check of its MTU problem ?
0
 
ucguyAuthor Commented:
Is there any one who knows how to check MTU problem  ?
0
 
ucguyAuthor Commented:
i am still working in this problem, is there  any idea ?
0
 
David Johnson, CD, MVPOwnerCommented:
I highly doubt that it is a MTU problem

ping example.com -f -l xxxx
-l = lower case letter L
xxxx packet size

The normal MTU is 1500
C:\Users\David Johnson>ping google.com -f -l 1475
Pinging google.com [66.185.95.25] with 1475 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 66.185.95.25:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\David Johnson>ping google.com -f -l 1473
Pinging google.com [66.185.95.25] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 66.185.95.25:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\David Johnson>ping google.com -f -l 1472
Pinging google.com [66.185.95.25] with 1472 bytes of data:
Reply from 66.185.95.25: bytes=1472 time=17ms TTL=58
Reply from 66.185.95.25: bytes=1472 time=13ms TTL=58
Reply from 66.185.95.25: bytes=1472 time=17ms TTL=58
Reply from 66.185.95.25: bytes=1472 time=13ms TTL=58
Ping statistics for 66.185.95.25:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 13ms, Maximum = 17ms, Average = 15ms

Open in new window

By trial and error I see that the optimum mtu is 1472
To find out what my configured MTU is .. from an elevated command prompt
C:\WINDOWS\system32>netsh interface ipv4 show subinterfaces

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  1500                1  7678156698  10595591033  Ethernet 2
4294967295                1       4065     114312  Loopback Pseudo-Interface 1
  1500                1          0     198527  VMware Network Adapter VMnet1
  1500                1          0     200471  VMware Network Adapter VMnet8

Open in new window

To set the mtu
C:\WINDOWS\system32>netsh interface ipv4 set subinterface "Ethernet 2" mtu=1472
store=persistent
Ok.

Open in new window

0
 
NVITCommented:
You said access via \\192.168.1.31\Sharename works.
Does \\192.168.1.31\c$ also work?
0
 
ucguyAuthor Commented:
We are working with Microsoft Support for this now. Will you know the solution.
0
 
NVITCommented:
I appreciate the update, ucguy. Thanks!
0
 
ucguyAuthor Commented:
customer has re-installed the file server again.

Please close this thread.
0
 
Seth SimmonsSr. Systems AdministratorCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
0

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 8
  • 4
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now