Mizerka Posted December 18, 2019 Share Posted December 18, 2019 can you ping it? cmd ping x.x.x.x try hostname as well; ping hostname.local Quote Link to comment
kocka Posted December 18, 2019 Author Share Posted December 18, 2019 C:\Users\karac>ping 192.168.88.192 -t Pinging 192.168.88.192 with 32 bytes of data: Reply from 192.168.88.192: bytes=32 time<1ms TTL=64 Reply from 192.168.88.192: bytes=32 time<1ms TTL=64 Reply from 192.168.88.192: bytes=32 time<1ms TTL=64 Reply from 192.168.88.192: bytes=32 time<1ms TTL=64 Reply from 192.168.88.192: bytes=32 time<1ms TTL=64 Reply from 192.168.88.192: bytes=32 time<1ms TTL=64 Reply from 192.168.88.192: bytes=32 time<1ms TTL=64 Ping statistics for 192.168.88.192: Packets: Sent = 7, Received = 7, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Control-C ^C C:\Users\karac> C:\Users\karac>ping ftp.local Pinging FTP.local with 32 bytes of data: Reply from time<1ms Reply from time<1ms Reply from time<1ms Reply from time<1ms Ping statistics for Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\Users\karac> but the local ping returns ipv6 address and i don`t have ipv6 configured on my network strange Quote Link to comment
Mizerka Posted December 18, 2019 Share Posted December 18, 2019 (edited) hmm those look fine, and you don't need dhcpv6 for ipv6 devices to work, apipa v4 169.254 is a pain to use, but ipv6 fixes that and can manage itself on networks without dns quite painlessly, win10 prefers it by default. anyway, doubt it'll be it, but you can try disabling ipv6 on your client interface to force it on v4, but network discovery worked fine over v6 by the looks. win+r NCPA.CPL default eth int, and untick ipv6. also you don't have any firewalls/av in place that might prevent it? try disabling win firewall (temporarily if you actually use it) e; also make sure you have enabled discovery and filesharing on network/s (just add to all for now), found in network and sharing center. Edited December 18, 2019 by Mizerka Quote Link to comment
Frank1940 Posted December 18, 2019 Share Posted December 18, 2019 I went through your syslog and I am lifting out a section of it: Dec 18 15:39:15 FTP root: Starting Samba: /usr/sbin/smbd -D Dec 18 15:39:15 FTP root: /usr/sbin/nmbd -D Dec 18 15:39:15 FTP root: /usr/sbin/wsdd Dec 18 15:39:15 FTP root: /usr/sbin/winbindd -D Dec 18 15:39:15 FTP emhttpd: shcmd (20608): smbcontrol smbd close-share 'FTP' The first four lines are the normal starting of the SMB process. They occur whenever SMB restarts. The problem appears to be in this fifth line. Dec 18 15:39:15 FTP emhttpd: shcmd (20608): smbcontrol smbd close-share 'FTP' Googling smbcontrol smbd close-share is a command that apparently orders smbd to close the client connections to the named share (FTP in this case). Problem is that I don't have the foggiest idea what is generating this message. Quote Link to comment
Mizerka Posted December 18, 2019 Share Posted December 18, 2019 4 minutes ago, Frank1940 said: I went through your syslog and I am lifting out a section of it: Dec 18 15:39:15 FTP root: Starting Samba: /usr/sbin/smbd -D Dec 18 15:39:15 FTP root: /usr/sbin/nmbd -D Dec 18 15:39:15 FTP root: /usr/sbin/wsdd Dec 18 15:39:15 FTP root: /usr/sbin/winbindd -D Dec 18 15:39:15 FTP emhttpd: shcmd (20608): smbcontrol smbd close-share 'FTP' The first four lines are the normal starting of the SMB process. They occur whenever SMB restarts. The problem appears to be in this fifth line. Dec 18 15:39:15 FTP emhttpd: shcmd (20608): smbcontrol smbd close-share 'FTP' Googling smbcontrol smbd close-share is a command that apparently orders smbd to close the client connections to the named share (FTP in this case). Problem is that I don't have the foggiest idea what is generating this message. I'm pretty sure that's the default behaviour when making changes to a share that's already deployed. it kills off connections and relies on client to reestablish it. looking at my logs; it's specifically ran when changing smb security settings; below changing public to secure Dec 18 23:00:18 NekoUnRaid root: Starting Samba: /usr/sbin/nmbd -D Dec 18 23:00:18 NekoUnRaid root: /usr/sbin/smbd -D Dec 18 23:00:18 NekoUnRaid root: /usr/sbin/winbindd -D Dec 18 23:00:18 NekoUnRaid emhttpd: shcmd (509): smbcontrol smbd close-share 'ssd' Quote Link to comment
kocka Posted December 18, 2019 Author Share Posted December 18, 2019 i have a MikroTik RB951G-2HnD router if it helps . i still have no idea about the ipv6 address why it exist on my network it is from the unraid server but why when i have ipv4 only enabled Quote Link to comment
Mizerka Posted December 18, 2019 Share Posted December 18, 2019 Quote MikroTik RB951G-2HnD that looks retro anyways, tried applying those changes? since you can ping it and it echo's back then that's good enough, from here on, it'll be a layer 4 issue onwards, i'd still wager it's a microsoft service issue, got any other machines on network that can access this share btw? also looking at logs briefly, you have nameserver set to 193.231.252.1, typo or is that some strange public resolver you use? doesn't actually respond on 53 by the looks. Quote Link to comment
kocka Posted December 18, 2019 Author Share Posted December 18, 2019 (edited) yes i can whit my phone and windows 7 laptop, the ip is set by default by the router Edited December 18, 2019 by kocka Quote Link to comment
Mizerka Posted December 18, 2019 Share Posted December 18, 2019 (edited) Quote # Generated settings: IFNAME[0]="br0" BONDNAME[0]="bond0" BONDING_MIIMON[0]="100" BRNAME[0]="br0" BRSTP[0]="no" BRFD[0]="0" BONDING_MODE[0]="1" BONDNICS[0]="eth0" BRNICS[0]="bond0" PROTOCOL[0]="ipv4" USE_DHCP[0]="yes" DHCP_KEEPRESOLV="yes" DNS_SERVER1="192.168.88.1" DNS_SERVER2="193.231.252.1" DNS_SERVER3="213.154.124.1" USE_DHCP6[0]="yes" DHCP6_KEEPRESOLV="no" VLANS[0]="1" SYSNICS="1" those dns servers are a bit weird, first is likely your router, but other 2 are public and weird, I'd change to local router only probably, this is given out by your dhcp, i.e. router, again, strange. one of them points to some random location in Romania. and yeah ipv6 enabled so it picked up fe80:: Quote Dec 18 09:46:04 FTP ntpd[1663]: Listen normally on 3 br0 [fe80::1c20:77ff:fe46:fd3c%10]:123 should disable dhcp for something like unraid, it'll just cause you issues one day. Comparing my config to yours, there's nothing wrong unraid side and it doesn't report issues either. Make sure you have filesharing and discovery completely enabled e; Quote yes i can whit my phone and windows 7 laptop It will be windows 100%, unraid will use at least smb2 by default, so that's fine Edited December 18, 2019 by Mizerka Quote Link to comment
kocka Posted December 18, 2019 Author Share Posted December 18, 2019 (edited) it`s for testing and it shod still work. sharing and discovery is on and i can connect to others just not the server Edited December 18, 2019 by kocka Quote Link to comment
Mizerka Posted December 18, 2019 Share Posted December 18, 2019 (edited) 4 minutes ago, kocka said: it`s for testing and it shod still work. if anybody has any other ideas pls post sure, well I give up then, good luck. only other thing in terms of config is you have disk shares force enabled, you're better of using user shares or leaving it on auto default. and mounting disk outside of array if that's what you need. Edited December 18, 2019 by Mizerka Quote Link to comment
Frank1940 Posted December 18, 2019 Share Posted December 18, 2019 (edited) I don't think this is your problem but it is worth a try: https://www.windowproblemsolve.com/2019/05/you-can-not-access-this-shared-folder.html Edited December 18, 2019 by Frank1940 Quote Link to comment
kocka Posted December 18, 2019 Author Share Posted December 18, 2019 sorry didn't mean to offend hence the edit but my first experience whit unraid is not good basic share is not superpose to be so hard Quote Link to comment
kocka Posted December 18, 2019 Author Share Posted December 18, 2019 2 minutes ago, Frank1940 said: I don't think this is your problem but it is worth a try: https://www.windowproblemsolve.com/2019/05/you-can-not-access-this-shared-folder.html yeah did that to Quote Link to comment
JonathanM Posted December 19, 2019 Share Posted December 19, 2019 Just a WAG, but could you try renaming the server? I'm wondering if somehow windows is getting hung up on ftp being a reserved name of sorts. Quote Link to comment
trurl Posted December 19, 2019 Share Posted December 19, 2019 3 hours ago, Mizerka said: those dns servers are a bit weird, first is likely your router, but other 2 are public and weird, I'd change to local router only probably, this is given out by your dhcp, i.e. router, again, strange. one of them points to some random location in Romania. You can always return to default network settings by deleting the config/network.cfg file on flash Quote Link to comment
kocka Posted December 19, 2019 Author Share Posted December 19, 2019 thank you all for help im going to try freenas or stay on Ubuntu cuz this is ridiculous 6 days and i still cant see the share Quote Link to comment
trurl Posted December 19, 2019 Share Posted December 19, 2019 2 minutes ago, kocka said: thank you all for help im going to try freenas or stay on Ubuntu cuz this is ridiculous 6 days and i still cant see the share Most people don't have these problems. I suspect something odd about your network setup. Quote Link to comment
kocka Posted December 19, 2019 Author Share Posted December 19, 2019 even direct connect dose not work. Quote Link to comment
Frank1940 Posted December 19, 2019 Share Posted December 19, 2019 10 hours ago, jonathanm said: Just a WAG, but could you try renaming the server? I'm wondering if somehow windows is getting hung up on ftp being a reserved name of sorts. If you didn't try this, it is worthy suggestion. The ftp protocol is used on WIN10 and there could be some weird interaction going on here. Quote Link to comment
kocka Posted December 19, 2019 Author Share Posted December 19, 2019 re named to tower still the same Quote Link to comment
mwf369 Posted February 10, 2020 Share Posted February 10, 2020 I had the exact same issue as the OP in my Windows domain environment. This was extremely frustrating since the SMB shares were working fine for almost a month, then suddenly I could not connect to them with the very account I used to set the permissions with! I had used a domain admin account to set the permissions on the shares and granted full access to "domain admins", and less access to a couple user groups as appropriate. I discovered (from running the Fix Common Problems full scan) that UnRAID saw my domain admin account as a "domain user". I looked in Active Directory and realized it was a member of both groups. I set Domain Admins as the primary group for this account, removed domain users, and immediately I could access the UnRAID shares with this account again. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.