January 6, 200917 yr Hello, I cannot setup user shares, windows doesn't see them. I'm getting endpoint is not connected error on syslog. There are couple of topics about this already but no definite answer. Can someone please provide a clear guide on how to resolve this issue? I'm using winxp 64 bit and unraid server pro 4.4. Jan 6 01:04:58 Tower emhttp: shcmd (55): /usr/sbin/nmbd -D Jan 6 01:04:58 Tower emhttp: shcmd (56): /usr/sbin/smbd -D Jan 6 01:04:58 Tower kernel: md: import disk0: [8,0] (sda) SAMSUNG HD103UJ S13PJDWQA20209 offset: 63 size: 976762552 Jan 6 01:04:58 Tower kernel: md: import disk1: [8,16] (sdb) SAMSUNG HD103UJ S13PJ90QC16806 offset: 63 size: 976762552 Jan 6 01:04:58 Tower kernel: md: import disk2: [8,32] (sdc) ST31000340AS 6QJ02VLB offset: 63 size: 976762552 Jan 6 01:05:02 Tower kernel: md: import disk0: [8,0] (sda) SAMSUNG HD103UJ S13PJDWQA20209 offset: 63 size: 976762552 Jan 6 01:05:02 Tower kernel: md: import disk1: [8,16] (sdb) SAMSUNG HD103UJ S13PJ90QC16806 offset: 63 size: 976762552 Jan 6 01:05:02 Tower kernel: md: import disk2: [8,32] (sdc) ST31000340AS 6QJ02VLB offset: 63 size: 976762552 Jan 6 01:05:05 Tower kernel: md: import disk0: [8,0] (sda) SAMSUNG HD103UJ S13PJDWQA20209 offset: 63 size: 976762552 Jan 6 01:05:05 Tower kernel: md: import disk1: [8,16] (sdb) SAMSUNG HD103UJ S13PJ90QC16806 offset: 63 size: 976762552 Jan 6 01:05:05 Tower kernel: md: import disk2: [8,32] (sdc) ST31000340AS 6QJ02VLB offset: 63 size: 976762552 Jan 6 01:05:06 Tower kernel: md: import disk0: [8,0] (sda) SAMSUNG HD103UJ S13PJDWQA20209 offset: 63 size: 976762552 Jan 6 01:05:06 Tower kernel: md: import disk1: [8,16] (sdb) SAMSUNG HD103UJ S13PJ90QC16806 offset: 63 size: 976762552 Jan 6 01:05:06 Tower kernel: md: import disk2: [8,32] (sdc) ST31000340AS 6QJ02VLB offset: 63 size: 976762552 Jan 6 01:05:06 Tower emhttp: shcmd (57): killall -w smbd nmbd Jan 6 01:05:08 Tower emhttp: shcmd (58): /usr/sbin/nmbd -D Jan 6 01:05:08 Tower emhttp: shcmd (59): /usr/sbin/smbd -D Jan 6 01:05:08 Tower kernel: mdcmd (137): start Jan 6 01:05:08 Tower kernel: md: import disk0: [8,0] (sda) SAMSUNG HD103UJ S13PJDWQA20209 offset: 63 size: 976762552 Jan 6 01:05:08 Tower kernel: md: import disk1: [8,16] (sdb) SAMSUNG HD103UJ S13PJ90QC16806 offset: 63 size: 976762552 Jan 6 01:05:08 Tower kernel: md: import disk2: [8,32] (sdc) ST31000340AS 6QJ02VLB offset: 63 size: 976762552 Jan 6 01:05:08 Tower kernel: unraid: allocated 7096kB Jan 6 01:05:08 Tower kernel: md1: running, size: 976762552 blocks Jan 6 01:05:08 Tower kernel: md2: running, size: 976762552 blocks Jan 6 01:05:09 Tower kernel: mdcmd (139): check Jan 6 01:05:09 Tower emhttp: shcmd (60): mkdir -m 700 /mnt/disk1 Jan 6 01:05:09 Tower kernel: md: recovery thread woken up ... Jan 6 01:05:09 Tower emhttp: shcmd (60): mkdir -m 700 /mnt/disk2 Jan 6 01:05:09 Tower emhttp: shcmd (61): mount -t reiserfs -o noatime,nodiratime /dev/md1 /mnt/disk1 >/dev/null 2>&1 Jan 6 01:05:09 Tower emhttp: shcmd (61): mount -t reiserfs -o noatime,nodiratime /dev/md2 /mnt/disk2 >/dev/null 2>&1 Jan 6 01:05:09 Tower kernel: md: recovery thread has nothing to resync Jan 6 01:05:09 Tower kernel: ReiserFS: md2: found reiserfs format "3.6" with standard journal Jan 6 01:05:09 Tower kernel: ReiserFS: md2: using ordered data mode Jan 6 01:05:09 Tower kernel: ReiserFS: md1: found reiserfs format "3.6" with standard journal Jan 6 01:05:09 Tower kernel: ReiserFS: md1: using ordered data mode Jan 6 01:05:09 Tower kernel: ReiserFS: md2: journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jan 6 01:05:09 Tower kernel: ReiserFS: md2: checking transaction log (md2) Jan 6 01:05:09 Tower kernel: ReiserFS: md1: journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jan 6 01:05:09 Tower kernel: ReiserFS: md1: checking transaction log (md1) Jan 6 01:05:09 Tower kernel: ReiserFS: md1: Using r5 hash to sort names Jan 6 01:05:09 Tower kernel: ReiserFS: md2: Using r5 hash to sort names Jan 6 01:05:09 Tower kernel: can't shrink filesystem on-line Jan 6 01:05:09 Tower kernel: can't shrink filesystem on-line Jan 6 01:05:09 Tower emhttp: shcmd (60): mkdir -m 700 /mnt/user Jan 6 01:05:09 Tower emhttp: shcmd: shcmd (60): exit status: 1 Jan 6 01:05:09 Tower emhttp: shcmd (61): /usr/local/sbin/shfs /mnt/user Jan 6 01:05:09 Tower emhttp: shcmd: shcmd (61): exit status: 1 Jan 6 01:05:10 Tower emhttp: _list_user_shares: scandir: Transport endpoint is not connected Jan 6 01:05:10 Tower emhttp: shcmd (62): killall -HUP smbd Jan 6 01:10:04 Tower emhttp: shcmd (63): mkdir -m 700 '/mnt/user/Music' Jan 6 01:10:04 Tower emhttp: shcmd: shcmd (63): exit status: 1 Jan 6 01:10:04 Tower emhttp: shcmd (64): mkdir -m 700 /mnt/user Jan 6 01:10:04 Tower emhttp: shcmd: shcmd (64): exit status: 1 Jan 6 01:10:04 Tower emhttp: shcmd (65): /usr/local/sbin/shfs /mnt/user Jan 6 01:10:04 Tower emhttp: shcmd: shcmd (65): exit status: 1 Jan 6 01:10:05 Tower emhttp: _list_user_shares: scandir: Transport endpoint is not connected Jan 6 01:10:05 Tower emhttp: shcmd (66): killall -HUP smbd Jan 6 01:17:06 Tower in.telnetd[1905]: connect from 192.168.1.13 (192.168.1.13) Jan 6 01:17:09 Tower login[1906]: ROOT LOGIN on `pts/0' from `192.168.1.13' Jan 6 01:19:19 Tower emhttp: shcmd (67): mkdir -m 700 '/mnt/user/Music' Jan 6 01:19:19 Tower emhttp: shcmd: shcmd (67): exit status: 1 Jan 6 01:19:19 Tower emhttp: shcmd (68): mkdir -m 700 /mnt/user Jan 6 01:19:19 Tower emhttp: shcmd: shcmd (68): exit status: 1 Jan 6 01:19:19 Tower emhttp: shcmd (69): /usr/local/sbin/shfs /mnt/user Jan 6 01:19:19 Tower emhttp: shcmd: shcmd (69): exit status: 1 Jan 6 01:19:20 Tower emhttp: _list_user_shares: scandir: Transport endpoint is not connected Jan 6 01:19:20 Tower emhttp: shcmd (70): killall -HUP smbd Best regards
January 6, 200917 yr There is no 'definite answer' or 'clear guide' at this point, only reports of various failures of the User Shares system in v4.4 final, and later. There have been a couple of reports of workarounds that appeared to allow a few users to run acceptably well, but in general the only current answer is to continue to patiently wait for an official answer, and/or a new release. If you depend on the User Share features right now, then revert to either v4.3.3 or v4.4-beta2. Both have been well tested with User Shares, no reports of problems. Just download the zip file from the Lime Technology downloads site, and extract bzroot and bzimage to your flash drive, and stop the array and reboot. See the Release Notes page for the differences between versions.
Archived
This topic is now archived and is closed to further replies.