Error 2 Share Not Available

raydon said:
Thanks af123, see my edit above. I've just checked and the config I downloaded today has the exact same size and date as the one I downloaded in 2011 i.e. 30810 bytes 24/09/2010 14:45, so it would appear that they are not keeping their sources up to date.:(
Click to expand...
Yep. Same with the kernel source code tarball. There were definite differences between 1.02 & 1.03 though. This might help find out what:

Code: 
# strings -n10 1.02.32/kernel >| k.2
# strings -n10 1.03.06/kernel >| k.3
# gdiff -u k.2 k.3
--- k.2 2014-03-07 16:11:12.317509992 +0000
+++ k.3 2014-03-07 16:11:19.175071015 +0000
@@ -1,7 +1,7 @@
<|yB$@=c$t
<x[r$DWP$1
-<@bU$Xbv$!
-Linux version 2.6.18-7.1 (syji@syji-desktop) (gcc version 4.2.0 20070124 (prerelease) - BRCM 11ts-20090508) #1 SMP Sun Mar 25 18:30:38 KST 2012
+<PbU$hbv$!
+Linux version 2.6.18-7.1 (dhkim2@localhost.localdomain) (gcc version 4.2.0 20070124 (prerelease) - BRCM 11ts-20090508) #1 SMP Wed Mar 6 07:27:02 KST 2013
2.6.18-7.1 SMP mod_unload MIPS32_R1 32BIT gcc-4.2
ext3_new_blocks
ext3_try_to_allocate_with_rsv
@@ -4564,7 +4564,7 @@
sha_transform
csum_partial_copy_nocheck
2.6.18-7.1
-#1 SMP Sun Mar 25 18:30:38 KST 2012
+#1 SMP Wed Mar 6 07:27:02 KST 2013
7405b0-smp
Exception vector 0 called
Exception vector 1 called
@@ -4685,12 +4685,12 @@
psmouse.proto
performance
pfifo_fast
-tcp_bic.smooth_part
-tcp_bic.initial_ssthresh
-tcp_bic.beta
-tcp_bic.low_window
-tcp_bic.max_increment
-tcp_bic.fast_convergence
+tcp_cubic.tcp_friendliness
+tcp_cubic.bic_scale
+tcp_cubic.initial_ssthresh
+tcp_cubic.beta
+tcp_cubic.max_increment
+tcp_cubic.fast_convergence
/e754_xcpt
oYelf_libr
SetP?TxRxC
@@ -4699,6 +4699,7 @@
250MHZhwbug
cm1250_m3_w
iso8859_15
+<( d$0 Q$+
<`N0&xNd&E
<DTC$PT%%DTN
initcall_debug

Looks like they backported some of the changes to the 2.6.19 kernel.
 
@af123, from one of the date-stamp lines above (Sun Mar 25 18:30:38 KST 2012) it looks like you are comparing 1.03.06 to 1.02.27, not 1.02.32. Apologies if I have misinterpreted the code.
 
You're right. The confusion is that I was looking at the kernel extracted from my 1.02.32 box rather than the one that came with 1.02.32. Same difference though, it does look like they tweaked the kernel for 1.03.xx as well as adding new kernel tuning parameters that are configured at boot time.
 
I have seen posts which indicate that boxes with 1.03.xx versions can format and align 2TB advanced format disks: here. Is this a feature that is incorporated into the kernel, or would it be accomplished by a separate executable?
 
af123 said:
Yep. Same with the kernel source code tarball. There were definite differences between 1.02 & 1.03 though. Looks like they backported some of the changes to the 2.6.19 kernel.
Click to expand...
Yes, looks like they backported CUBIC TCP congestion control to replace BIC. CUBIC wasn't introduced as default till 2.6.19.
I'd be more interested in exactly what changes have been made to the humaxtv binary.
 
My response to cat /proc/version:

Code: 
Linux version 2.6.18-7.1 (jinkh@jinkh-build-server) (gcc version 4.2.0 20070124 (prerelease) - BRCM 11ts-20090508) #1 SMP Fri Feb 7 14:15:02 KST 2014

Mine was running 1.02.32 with cust f/w and then got the OTA update. I installed the 1.03.12 w 2.22 cust firmware once I realised my custom firmware had gone (sorry, wasn't keeping up with the forum at the time..)

After the update, samba was working fine for a few days. Noticed a problem last night and again this morning.
 
I think the cause of problem here may not be the kernel or the CF version but the update to the samba package which occurred last week. If the OP had not previously modified smb.conf in any way then it would have been updated. This would have changed the share names from "media" to "My Video", "My Photo" etc. There is a valid reason for this change; some people were having problems with a small disk size being reported for the media share.

The solution is to setup the client to match the new names.
 
I added a line which says:
Code: 
include = /mod/etc/smb-user.conf
to /mod/etc/smb.conf and then put my own shares in /mod/etc/smb-user.conf

Might I suggest this as an enhancement to the package?
 
prpr said:
I added a line which says:
Code: 
include = /mod/etc/smb-user.conf
to /mod/etc/smb.conf and then put my own shares in /mod/etc/smb-user.conf

Might I suggest this as an enhancement to the package?
Click to expand...
You can always add your own shares to /mod/etc/smb.conf
 
I know and I used to, but if the file ever gets updated by a package revision then it would just work without any (or as much - I change the workgroup) manual editing.
 
I wasn't aware that I had ever modified the Samba share file (I guess I must have done a long time ago) and I was bitten by this bug. I even removed the Samba package and re-installed and it still didn't work (guess the modified file didn't get removed and was still there on re-installation).

When updating things like Ubuntu, the installation scripts at least try and warn the user that there are modified configuration scripts around and ask to merge/overwrite/keep etc so the user gets some awareness of changes occurring. Is there a way for this to be done with the current package management? Because the first I knew of an incompatible change is when something didn't work for me, and I didn't know why.

Thanks for all the effort on the custom firmware, though...
 
Trevor Jasper said:
I wasn't aware that I had ever modified the Samba share file (I guess I must have done a long time ago) and I was bitten by this bug. I even removed the Samba package and re-installed and it still didn't work (guess the modified file didn't get removed and was still there on re-installation).
Click to expand...
You would have "been bitten" by this bug if you had not modified the smb.conf file. The package management sofwtare recognises this as a config file and will not replace it if it has been modified by the user.
When updating things like Ubuntu, the installation scripts at least try and warn the user that there are modified configuration scripts around and ask to merge/overwrite/keep etc so the user gets some awareness of changes occurring. Is there a way for this to be done with the current package management? Because the first I knew of an incompatible change is when something didn't work for me, and I didn't know why.
Click to expand...
When updating a package the package management software will warn you that it has found a modified config file and state that it has created a new file with "-opkg" appended to the filename (e.g. smb.conf-opkg) in this case. Since you had not modified the smb.conf file you would not have received this message.
 
The default share names had changed. If you had edited the file, the new one didn't replace the old, so your old share names didn't change.
 
I don't understand. I wasn't mounting the shares under windows or anywhere else, just trying to access them from Explorer, which has worked seamlessly since the beginning. Changing the share names in the recent update shouldn't have had any effect in that scenario, should it?.....:(

Edited to add...
I have just been using Explorer to point at the IP address and browse the shares from there. Have the shares become non-browsable somehow?
 
You must log in or register to reply here.
Back
Top