Bailey, I've noticed you've done some recent work on SMB mounts.  I think this relates to your work.

Curtis, thanks for opening a bug. I believe I've been able to reproduce the issue. Is this understanding of your share setup correct? hiddenshare$ is a hidden share that all users are able to authenticate to (enforced via the share permissions) and then each user has their own folder which only they have access to (file permissions or similar). I want to be sure our test setup is correct. Thanks!

Bailey, you are correct on the setup.  We actually have a share exactly like that and another share with a hidden $ name where authenticated users all have the same level of access to all folders for sharing data across departments.  This type also does not work.

Okay glad we have the setup correct. It seems to be an issue with the way we authenticate when mounting to folders within shares. Since M69 cuts Thursday we will get a fix in M70. Could you let me know if mounting server.fqdn/hiddenshare$ and the non-hidden share works? 

I'm able to map to a share as long as the share path does not have a $ in it using the SMB naming convention.

Sorry for being verbose, but could you let me know about the outcome of the following situations

- Mapping smb://server.fqdn/visableshare with credentials
- Mapping smb://server.fqdn/visableshare/folder with credentials
- Mapping smb://server.fqdn/hiddenshare$ with credentials
- Mapping smb://server.fqdn/hiddenshare$/folder with credentials

Thanks!

Not a problem.

- Mapping smb://server.fqdn/visableshare with credentials - This works
- Mapping smb://server.fqdn/visableshare/folder with credentials - This works
- Mapping smb://server.fqdn/hiddenshare$ with credentials - This does not work
- Mapping smb://server.fqdn/hiddenshare$/folder with credentials - This does not work

Thanks! As a follow up, with smb://server.fqdn/hiddenshare$ with credentials, is the error message the same as the one in the attached image (Please check your credentials and try again)?

Correct.

Bailey, has there been in progress on this?

Hi Curtis, 

I think we know what is required to fix this and are hoping to get the fix in to M70. 

Great news, I know our corporation is very excited to try out this native feature.  Thanks for the update.

FYI, in OS version Version 69.0.3497.35 (Official Build) beta (64-bit) I just tried to add SMB Shares to see if there was any change. I briefly saw the new look of the SMB app and then Chrome crashed and restarted.

Move to M71. The fix for this will be in M71.

Curtis - re the crash, can you try again in M70. If you still see it could you post some repro steps.

Thanks

zentaro, I've since switched to a Pixelbook and have not see this issue on 68.  Also I can confirm that I can map hidden shares in the following ways.  Please keep in mind this does not resolve the original problem as I can only map one level deep on a hidden share, examples below.

Can map
\\fqdnservername\hiddenshare$

Can not map
\\fqdnservername\hiddenshare$\nonhiddenshare, ie, server\home$\user_name

Thanks. Yes we are aware of the nested issue. It's 872405. The CL's to fix this are still in review and it will be fixed in 71.

Since 70 is the first version we plan on supporting for native SMB, some functionality may be broken/missing in 68/69. But any bugs that repro in M70 or later we'd like to know about.

Not a problem, if I see any I'll report them.

This should be fixed in 71.

 crbug.com/872405 

Thanks for the update, I'm on beta 70 right now.  After the update I received yesterday I tested again but still see the issue.  I'll keep an eye out for 71.

I was able to map the following share with authentication in 71:

\\fqdnservername\hiddenshare$\nonhiddenshare

Chrome OS: 11151.24.0
Chrome: 71.0.3578.45
Device: Nautilus

Marking this as Verified, please feel free to reopen if you have any issues.

I just got version 71.0.3578.49, I'm afraid it's not working for me.  I've attached two screenshots showing the attempt.

Deleted: Screenshot 2018-11-14 at 2.09.18 PM.png 14.3 KB

	Screenshot 2018-11-14 at 2.09.18 PM.png 14.3 KB View Download

Deleted: Screenshot 2018-11-14 at 2.09.23 PM.png 33.7 KB

	Screenshot 2018-11-14 at 2.09.23 PM.png 33.7 KB View Download

Hey Curtis,

Thanks for following up. Are you using Kerberos? Could you try using the format user@workgroup rather than workgroup\user and report back? Additionally, are you able to mount other shares that require credentials using a credential of this format, or does this only occur on hidden shares?

I don't know what they have implemented at the corp level for logins.  I tried using am@a_curtis_pogue using the path \\cos1amfpsw01.am.sanm.corp\home$\curtis_pogue and got the same error in the second screenshot.

It appears this format no longer works in this version, it had in the previous beta version.  I was able to login with either the SMB format or this format.

\\cos1amfpsw01.am.sanm.corp\home$ and \\cos1amfpsw01.am.sanm.corp\data1$ worked and now neither work.

for the credential, I believe the format should be a_curtis_pogue@am

Also, could you please try this format:

smb://cos1amfpsw01.am.sanm.corp/home$ 
smb://cos1amfpsw01.am.sanm.corp/data1$ 

with the credentials both ways?

Thank you!

I tried mapping to smb://cos1amfpsw01.am.sanm.corp/home$/curtis_pogue using the format a_curtis_pogue@am and still get the error in the above screenshot.

I wanted to report, yesterday and today with release 71.0.3578.71 (Official Build) beta (64-bit) I am now able to map to a secondary level as in the example below and in the screenshot.  I found I have to fully qualify my login as in am.sanm.corp\a_curtis_pogue

\\cos1amfpsw01.am.sanm.corp\home$\curtis_pogue 

Deleted: Screenshot 2018-11-29 at 10.13.41 AM.png 13.3 KB

	Screenshot 2018-11-29 at 10.13.41 AM.png 13.3 KB View Download

Just as a sanity test, can you also verify that username

a_curtis_pogue@am.sanm.corp works too?

Yes, that login format also works.  I'm using the UNC naming convention.