Possibly solved the x64 Sharing Issue

Coordinator
Nov 30, 2010 at 7:36 PM
Edited Nov 30, 2010 at 7:54 PM

I just tested this on my x64 Win 7 pro so will probably work on the other x64 OS's and probably win 7 Ulitmate as well.

  1. Open regedit
  2. Go to HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
  3. Add a new DWORD called Smb2 (Leave the value at zero)
  4. Reboot
  5. Setup the Share as you normally would via "Computer Management" -> "System Tools" -> "Shared Folders" -> Share; right click "New Share..."
  6. Use the Advanced setting in Liquesce and discover the new share credentails and save tham
  7. Send the new settings to the Liquesce service.
  8. Traverse to the share

If for some reason step 8 does not work, then just reboot again (As this is the first time a share has been enabled since the SMB2 protocol has been used some things need to "Settle"), but could be due to the client OS that is accessing this share (See below)

After tha I could navigate straight to the share and it did not report the "Incorrect Function" message.

Let me know how you get on with this setting.

I also did the settings in here (http://support.microsoft.com/kb/232271) to speed up my Network access, not sure they worked, as it turned out my Media-Vault already had them turned on !

Coordinator
Nov 30, 2010 at 7:51 PM
Edited Nov 30, 2010 at 7:53 PM

Seems that their may be some additional steps if you are the Client attaching to the share.. Please see the commandline settings in the following link if the registry setting above does not work on your client machine accessing the  x64 Liquesce host:

http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

Quote from the above website

"When using the terms "client" and "server" in case of file and print sharing, it does not necessarily mean that a client-type OS such as Vista "always" connects to a server-type Os such as Windows Server 2008. Sometimes, a Vista computer will connect to another Vista computer, and in that case, the computer that is "serving" the shares is considered to be the "server"."

 

Coordinator
Nov 30, 2010 at 8:19 PM

I've just checked my network sharing settings and see that I have them set (Mostly) in this way (To probablt firce SMB usage)

http://www.networkedmediatank.com/wiki/index.php/Windows7

BUT, I still had 128 Bit encryption on, About to test the No-sharing password protection settings

Coordinator
Nov 30, 2010 at 8:34 PM

Can you tell that I've been testing this madly.....

Anyway, it appears that there may also be an Smb3 setting as well : http://wdtvforum.com/main/index.php?topic=3040.0

I also modified the Liquesce service to be just Automatic (instead of Automatic delayed), and set the delay offset in the management Gui to be just 250ms.. This means that by the time I have actually logged into the machine after a reboot, the sharing and everything else has already been recovered, by the service .. Yay !

So over to you users out there to confirm my findings..

Nov 30, 2010 at 9:35 PM

read this late tonight... I will possibly try some of this tomorrow...

questions:

1) Will this solve both the need to restart server service AND accessing the shares?

2) What you mean "traverse the share"? Open it from a client?

3) Can you make a cleaner single post with the steps you want us to try both in server and client?

 

Nov 30, 2010 at 11:54 PM
Edited Dec 1, 2010 at 1:09 AM

Hi,

Just want to confirm that the above solution worked for me. To help anyone else I will quickly post my setup:

 

Server  - is Windows Server 2008 R2 (disParity server with my drives / shares) (needs SMB2 & SMB3 registry edit)

Client1 - Windows 7 64bit (needs SMB2 & SMB3 registry edit)

Client2 - Windows 7 32bit (needs SMB2 & SMB3 registry edit)

Client3 - Windows XP 32bit (NO registry edit required)

 

Create on your desktop the following file "SMB2-3.reg" and using notepad edit the file and add the following to it:

=== C/P below this line ===

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters]
"SMB3"=dword:00000000
"SMB2"=dword:00000000

=== END C/P above this line ===

 

FYI,

If you have any other shares on the "Server" or "Client(s)" that have the registry edited, keep in mind that other computers that don't have this registry edited will not be able to access the shares.

 

smurfiv

I would like to say that you have made my day with this solution as I have tried to use your app before without success. Thank you for all the hard work you have done!

Dec 1, 2010 at 9:30 AM

Again, so this solves sharing after reboot? Solves share access on x64? Both?

Also, does this mean we DISABLE SMB2 and SMB3 on those machines? Hmmm... I am not sure everybody will love that.

 

I will try later tonight.

 

Coordinator
Dec 1, 2010 at 3:49 PM
NLS wrote:

1) so this solves sharing after reboot?

2) Solves share access on x64? Both?

3) Also, does this mean we DISABLE SMB2 and SMB3 on those machines? Hmmm... I am not sure everybody will love that.

1) That was solved a while ago.. It was always working on XP and Win 7 x32- Just remeber to let Liquesce know about the share via Save and then Send (See the end of this page http://liquesce.codeplex.com/wikipage?title=Advanced%20Settings )

2) Yes x64 and probably Ultimate x32 as well

3) SMB 1 still works, and unless all the systems are SMB2.1 (i.e. no XBox, or NAS devices) then it will prbably be more stable.

SMB2.1 is the recommomended way to go, but I'm not sure that is the default for Win 7 (Just 2.0!) as this introduced proper backward compatability and Large transfer chunking (i.e. 1MB instead of 64KBytes). I have not installed that unless it sneaked in via an MS update !!

Dec 2, 2010 at 8:55 AM

1) Erm, not with the latest beta, with SBS7 (i.e. 2008R2 of course x64) and Win7 x86 client... Did I miss something? Because currently after SBS reboot I need to login just to restart server service (and the 3-4 services that depend on it).

3) I think Win7 indeed uses SMB2.1 by default. I think even Vista after SP1 (but not sure). There is no SMB3 so I guess that SMB3 key is about it. In any case this is a "workaround" not a solution. Workarounds are ok if there is a solution at least as an idea on a drawing board.

 

Coordinator
Dec 2, 2010 at 9:59 AM

1) Still sounds like you have not saved the Share information with Liquesce.. What does your config have in it ?

Found in "${specialfolder:folder=CommonApplicationData}/LiquesceSvc"

3) This workaround is probably better than me writing a client enabler (That only 1 person has downloaded !!) and introducing further complications (i.e. unknowns)

Dec 2, 2010 at 1:31 PM

1) Will check it out. Were?

3) I agree. Again, will feel better if we know what actually IS the problem and (some day) work towards a proper solution.

 

Coordinator
Dec 2, 2010 at 2:16 PM
NLS wrote:

1) Will check it out. Were?

Found in "${specialfolder:folder=CommonApplicationData}/LiquesceSvc"

Which is NLog terminlogy for the Common Application Data location, which on Win 7 is "C:\ProgramData"; then add the directory /LiquesceSvc

And the config file is called Properties.config.xml

It should have something similar to the following if they have been sent to the service
 <SharesToRestore>
    <LanManShareDetails>
      <Name>Kylie Minogue</Name>
      <Path>N:\Kylie Minogue</Path>
      <Description />
      <MaxConnectionsNum>4294967295</MaxConnectionsNum>
      <UserAccessRules>
        <UserAccessRuleExport>
          <DomainUserIdentity>BUILTIN\Administrators</DomainUserIdentity>
          <AccessMask>FULLCONTROL_NTFS</AccessMask>
          <InheritanceFlags>ObjectInheritAce ContainerInheritAce</InheritanceFlags>
          <Type>AccessAllowed</Type>
        </UserAccessRuleExport>
        <UserAccessRuleExport>
          <DomainUserIdentity>Win7-Dev\Simon</DomainUserIdentity>
          <AccessMask>FULLCONTROL_NTFS</AccessMask>
          <InheritanceFlags>ObjectInheritAce ContainerInheritAce</InheritanceFlags>
          <Type>AccessAllowed</Type>
        </UserAccessRuleExport>
      </UserAccessRules>
    </LanManShareDetails>
  </SharesToRestore>

Dec 2, 2010 at 3:22 PM

Not sure is this is related to SMB but I'm getting the following error when trying to play any media using VLC:

( Your input can't be opened: VLC is unable to open the MRL 'file:///X:/TV%20Shows/Stargate%20Universe/Stargate.Universe.S02E10.720p.HDTV.x264-CTU.mkv'. Check the log for details. )

 

I checked for log file but I can find it, I even googled where VLC stores the log files but I still can't find one.

 

Try the same file with Media Player Classic and everything works.

 

Also I tried playing the same file with VLC again but this time navigated to a regular network share not the Liquesce Mounted Drive, and the file plays fine.

 

Seams to be an issue with VLC not being able to properly access the files when they are shared from a Liquesce Mounted Drive.

 

Coordinator
Dec 2, 2010 at 5:08 PM
PCWiz wrote:

I'm getting the following error when trying to play any media using VLC:( Your input can't be opened: VLC is unable to open the MRL 'file:///X:/TV%20Shows/Stargate%20Universe/Stargate.Universe.S02E10.720p.HDTV.x264-CTU.mkv'. Check the log for details. )

I've opend an issue for you to add extra  and correct information into "http://liquesce.codeplex.com/workitem/7812"

Please can you add "Trace a log" to that workitem please?

See "http://liquesce.codeplex.com/wikipage?title=How%20To%20Get%20Logs"

Dec 6, 2010 at 1:05 PM

This is great news.  I've just moved to x64.  Will give it a try this week

Jan 9, 2011 at 11:17 AM

Dokan has been updated to solve the x64 issue!

http://code.google.com/p/dokan/issues/detail?id=168

Coordinator
Jan 9, 2011 at 6:05 PM

I am aware of the fix (And others I have helped with :) ) and have stopped developing my client workaround (For the moment) - Not sure how others managed to "Work-around the issue" when the driver needed to be fixed, Perhaps they do not understand LPGL or didn't want to give back to the developer(s) ?!?

Jan 10, 2011 at 10:51 AM

I'm not really sure what this means for Liquesce, when will the sharing bug be fixed, when the next build of Dokan is released?

Jan 11, 2011 at 9:53 AM

Dokan is at version 0.6.0, but Liquesce requires version 0.5.3 and will not install. Could this requirement be changed to see if the sharing issue has truly been fixed?

Coordinator
Jan 11, 2011 at 10:08 AM
Edited Jan 11, 2011 at 5:11 PM

I'll get onto testing this (Possibly) tonight..

The other way is to install 0.5.3, then Liquesce, (uinstall 0.5.3 and reboot) then install 0.6.0 (reboot) to help perform some of the testing your self :-)

Please report any progress back, Thanks for keeping me posted.

Jan 11, 2011 at 1:33 PM

I just uninstalled Dokan 0.5.3 and upgraded to Dokan 0.6.0.  I can now access my mapped liquesce share and play my MKVs on my Windows 7 x64 fileserver from Windows 7 32 bit and Windows 2008 R2 64 bit computers.

Well done to everyone who got this sorted.

Jan 12, 2011 at 2:20 PM

Wait let's sum up a bit.

The new Dokan solves ACCESS problems on the shares?

What about automatic "re-enabling" of shares after reboot? Is that solved?

(btw I am writing and not testing because my SBS7 told me last Friday that it expires on Monday! WAYTOGO MICROSOFT! A big "thanks" to beta testers my a*s... Anyway I had to crash-dive into setting a new SBS2011 in place and migrating as much as possible... THEN my main workstation at home decided to destroy its common user profile and pretty much make all other profiles suck... So I am in line for a new Win7 setup for this too... Plus I has a prometric test today... It was a 1.5 hour MSFT test... Made it in 14 minutes, 976/1000... They shouldn't make a CIO with 26 years experience take basic tests)

 

 

Coordinator
Jan 12, 2011 at 4:18 PM
Edited Jan 12, 2011 at 5:46 PM
NLS wrote:

1) The new Dokan solves ACCESS problems on the shares?

2) What about automatic "re-enabling" of shares after reboot? Is that solved?

3)They shouldn't make a CIO with 26 years experience take basic tests)

1) According to the web pages, and my quick touch test using Win7 x64 and the notepad issue is solved as well.

2) This should have already been solved.. I will test again using x64 and x32

3) Ha - just shows how useful the tests are then. .:-o

 

Edits for

2: Just rebooted my Win 7 x64 Pro, and the share was renabled (For everyone) [Tested via the loopback in explorer] the Share for N$ was also enabled but I could not access it due to ACL restrictions - But I could access C$ so something wrong there

1: Checked notepad access via the network share access, and it works.. Yay :-)

Jan 15, 2011 at 9:27 PM

Just checking: Do we still need to disable driver signing check on x64 systems?

 

 

Coordinator
Jan 17, 2011 at 9:50 AM

This has never been the case with the Dokan releases

Jan 17, 2011 at 10:52 AM

Great. :)