This project has moved. For the latest updates, please go here.

samba cannot smbmount \\server\vc_shared_folder

Topics: Technical Issues
Aug 5, 2015 at 9:46 PM
Edited Aug 5, 2015 at 10:36 PM
I'm having difficulties getting shared folders to work under Win10Pro and VC1.12-B.

Under C:, not encrypted, vanilla Win10, I can create a folder c:\shared_c; Share with Specific People; pick the pre-selected username@hotmail.com, click Share and I'm done. I can see, browse, copy to/from that folder from all of my other Windows PCs (let's keep NAS and linux outside this discussion for simplicity).

D: is whole drive encrypted with VC; mounted as a favorite, everything works locally. if I follow the same steps as above and create d:\shared_d; Share with Specific People; pick the pre-selected username@hotmail.com, click Share and I'm done.
Unfortunately, I can't seem to see or mount that folder from any other PC. I see it as a share but when I click to see the content of the folder I get "Windows cannot access \server\share_d. You don't have permission to access \server\share_d. Contact our network administrator to request access".

What's different with VC and sharing folders?

Thanks in advance!
Aug 8, 2015 at 4:07 AM
I've updated to 1.12 (not beta as of a couple of days ago) and I still can't mount folders shared from a VC encrypted partition. Anyone there that have done it successfully?

BUMP
Aug 9, 2015 at 3:37 PM
No one is sharing folders across PCs? I just did the same on an old PC. Installed Win10 on C: and TC encrypted only D:.
Sharing C:\shared_c works fine and I can see it an copy to/from my other Win10 PC just fine.
Sharing D:\shared_d is visible from my other Win10 PC but I get the same Access error.

Anyone?
Coordinator
Aug 9, 2015 at 6:50 PM
Hi,

This is a strange issue indeed, probably something has changed in Windows 10.

Can you please check the Event Viewer on the Windows 10 machine and look for any event that occur the same time as someone is trying to access the shared folder from an other machine?
Probably you'll find an entry that can explain the cause of this access error.

Also, I have just released VeraCrypt 1.13 few days after 1.12 in order to solve a compatibility issue with Tor Browser. Can you please install this new version just to be sure that this doesn't come from the same issue corrected in 1.13?

Meanwhile, I'll try to setup a configuration like yours but I'm not I can do this today.
Aug 11, 2015 at 12:20 AM
Hi @idrassi. Thank you for looking into my issue and trying to replicate it.

The system I was playing with is gone. This is a new setup.
1) I let Microsoft update my Win7 HTPC to Win10 Pro via their automated process.
2) created C:\Shared_on_C folder
3) right-mouse-click on it; Share With -> Specific People; selected the only user I have myusername@hotmail.com; hit the Share button; "Your folder is shared", Individual Items Shared_on_C (\HTPC)
4) attached an external USB drive; formatted it with VC-1.13 (upgraded, restarted before that); mounted that drive as Z:
5) created Z:\Shared_on_Z folder
6) right-mouse-click on it; Share With -> Specific People; selected the only user I have myusername@hotmail.com; hit the Share button; "Your folder is shared", Individual Items Shared_on_Z (\HTPC)
7) Visually, nothing looks suspicious when I run NET SHARE

Share name Resource Remark

C$ C:\ Default share
IPC$ Remote IPC
print$ C:\Windows\system32\spool\drivers
                                         Printer Drivers
ADMIN$ C:\WINDOWS Remote Admin
Shared_on_C C:\Shared_on_C
Shared_on_Z Z:\Shared_on_Z
Users C:\Users
The command completed successfully.

8) from my main Win10Pro PC I browsed the Network, saw my HTPC and when I double-click on it, I do see Shared_on_C, Shared_on_Z and Users
I do see the test files I had placed under Shared_on_C. I do see the normal stuff windows puts under Users. I did not have to logon to any of those shares, I assume, because I use the same myusername@hotmail.com account on both PCs.
When I double click on Shared_on_Z I get the same permissions error as before "Windows cannot access \HTPC\Shared_on_Z. You don't have permission to access \HTPC\Shared_on_Z. Contact our network administrator to request access".

Not sure what (and where) I should look for in eventvwr.msc. The events that I can see when I try to go into that directory are under under Windows Logs/Security and show generic Event IDs 4624 and 4634 (Audit Success for Account logon/logoff). All the other evens under Windows Logs appear to be some 45 minutes old, probably from when I restarted the PC after installing VC-1.13.

Any chance you got better results on your setup? Or could point me to something more specific I could test and search for?

TIA,
Marv
Aug 12, 2015 at 10:49 PM
Hello @idrassi. I guess you've not setup this to test. Meanwhile, I tried one more thing - had my c: encrypted with Bitlocker. Sharing continues to work on C: under Bitlocker and continues to NOT work on z: under VeraCrypt 1.13
Aug 24, 2015 at 4:27 PM
Edited Aug 28, 2015 at 5:46 PM
@idrassi, is folder sharing broken and that's the end of the thread? quick "I'm busy, will get back to you" would go a long way. thank you!
Coordinator
Sep 2, 2015 at 2:08 PM
First I would like you to have some understanding to huge work load associated with this open source project which makes the issue your reported only one of many other issues, posts and tickets opened on the tracker and on the forums.
Of course, you would like to see your issue handled quickly but the reality is there is a backlog of issues and yours is on the pipe and it will eventually be handled.

So please, use a better language and don't write posts as if you were a disgruntled customer asking for support: even in commercial software, there is often a one month delay before an opened ticket to be answered and analyzed, unless you have a dedicated SLA (which can cost a lot!), and you first posted on August 5 (less than one month ago).

Me and other on the forums are doing our best to give the best feedback possible as quick as possible. And users must accept to wait and no body is left since every post and issue is taken into account seriously.

Back to your issue:

I installed two Windows 10 machines (one home and one Pro) and I performed sharing tests exactly like you described. I used a unique Live ID to logon to both machines (the account associated with it is not administrator) and I used a USB key encrypted with VeraCrypt to do tests (NTFS filesystem). Like you, I shared a folder on this key and I selected the unique Live ID I use.
I performed the test in both directions: shared on Home and accessed from Pro and shared on Pro and accessed on Home.
In both cases, I was able to access the shared folder in Read/Write without any issue.

I also did tests by sharing the drive letter of the mounted VeraCrypt drive and it also worked in both cases.

So, this indicates that there is no sharing issue on Windows 10 with VeraCrypt and that you are just affected by an NTFS permission issue at the file system level.

This result is expected since VeraCrypt has no knowledge about the filesystem nor the access permissions. VeraCrypt only handles low level storage and when there is an issue, the error messages are relation to I/O access and bad parameters for calls but never related to permissions since these are handled above VeraCrypt.
The only double that existed was if Windows 10 had some strange new way of calling driver that maybe causing a side effect but my tests cleared that and we now know that VeraCrypt is not the culprit.
Sep 2, 2015 at 2:35 PM
marvinandro wrote:
@idrassi, that's the end of the thread? quick "I'm busy, will get back to you" would go a long way.

Mounir, I am very sorry you have read these selfish and ungrateful words towards you (unfortunately, not on the first time). This is very unfair and insulting especially in your case, when you dedicate so much time and energy to the project! I want you to know, that there are people, that know what it takes to develop a software (especially for FREE and in a sensitive filed of info-sec). In addition, on behalf of all the "normal" users of VeraCrypt, I/we say a very very big THANK YOU! Thank you for your hard work (and many times ungrateful, not to say, monetary unfavorable).

On the other hand, to marvinandro and egocentric users like him, I want to say: think before you say anything. And stop behaving like if the world is spinning around you.
It is not!

With great respect towards you, Mounir, and the VeraCrypt project,
algreider8.
Sep 2, 2015 at 5:24 PM
Hello @idrassi, thank you for getting back to me and I'm very sorry if the post came across in a negative way. Your "I'll try to setup a configuration like yours but I'm not I can do this today" on Aug 9th somehow put (unrealistic) expectation in my head that you're almost there, takes a few clicks to share a couple of folders, and that it'll happen "tomorrow" or perhaps the day after, hence my ping 2 weeks later.

My experience with community supported project wasn't about 1 month silence not only from one forum member but from the whole community. Anyhow, I stopped coding in the 90-ies and the the online world has change over the past few decades :)

I'll redo my tests again to see why it doesn't work at my end. As I described, one of the machines was built from scratch with the Insider version, I had attached an external HD, formatted it with VC (now at 1.14-beta), mounted it, created a folder and yes, I could see the folder from the other PCs but no, I could not even read the content of it or mount it. I had not played with any NTFS or other settings on that vanilla Insider Windows 10 Pro (just basic Next, Next, Next to set it up), same with the external HD.

I did reformat that external HD under Win10, created same folder, sharing just worked. Formatted one more time, this time also added BitLocker - Sharing worked. Again formatted with VC-1.14-beta.... no dice.

If you have any ideas what I should check for, please let me know. I'll try to put a few more hours into this during the long weekend and report back.

Take care!
Coordinator
Sep 3, 2015 at 11:06 PM
@algreider8: thank you for your support and you kind words.

@marvinandro: Apologies accepted. Online communication can be the source of many misunderstanding and they can also give the impression that everything is easy or quick.
Some issues get more attention from the community than others and this is often related to the number of people affected. The sharing issue your reported doesn't seem to be wide spread and this may explain the silence of other members compared of other posts and issues that are heavily commented.

One possible source of issue is how your user/Administrative accounts are configured on your machines. To check if this is the case, there is a simple test that you can do: Encrypt your drive with VeraCrypt but this time choose "None" as filesystem in the wizard. After that, mount the encrypted drive and then manually format it using Windows. Now, try to see if this makes any difference.

I propose this test because VeraCrypt perform NTFS formatting by calling a system API using UAC to get administrative privileges and this may cause access issues in some cases.
Sep 4, 2015 at 1:36 AM
Edited Sep 4, 2015 at 1:46 AM
Hi @adrassi. Thank you again for continuing to support me!

I'll try your order of formatting next. Let me report what I did last night and see if that'd shed any light as this time I went super clean.

I'm suspecting it has something to do with "Mount selected volume as removable medium" option. Or something else that's VeraCrypt specific.

New Win10Pro on my test laptop (t61 takes a while to install). The only thing I selected during the install was the mandatory time zone, login with my userid@hotmail.com (same as my other Win10Pro PC, I don't keep a second HoTMaiL account anymore). I left the internal C: untouched with NTFS, the way Win10Pro clean installs. partitions it and formats it.

For the test, created a folder C:\Shared_C. Shared it by right mouse clicking on it: Share with-->Specific People->Share. Just those 3 clicks. I didn't have to select anything as my userid@hotmail.com was preselected (the only ID on that new machine) and it was already with a permission of Owner.

Went to my other PC where I was logged in already with the same userid@hotmail.com, hit F5 to refresh the Network, saw \Shared_C, got in, copied a few files, painless setup to share a folder with 3 clicks. (I might give up Ubuntu one day, who knows).

Next, I connected to the laptop 2 USB drives (old WD, 1 TB and 500 GB).

First, the 1TB - partitioned and formatted with Win10 as NTFS and mounted as L. I created a folder Shared_L on it. Same 3 clicks and shared it. Back from my other PC, I could see Shared_L, copy files into it, delete them. Concluded that it's not a network or a Windows permissions issue, or that I'm using an external HD vs the internal one.

Repeated it on the 500GB - again, partitioned and formatted with Win10 as NTFS and mounted as V. Similarly created Shared_V, same 3 clicks, everything works. I can see it remotely, copy, delete, etc.

Next, I let Win10 encrypt L: with BitLocker. Left the process crunch overnight.
Similarly, I followed VeraCrypt's wizard and let it encrypt V: overnight.

Both steps had completed by this evening. I added V: to VeraCrypt's Favorites to make it easy to mount and selected only "Mount selected volume as removable medium".

Went back to my other PC and felt no difference on Shared_L. My files were still there, I could still copy more, delete, etc. If it wasn't my PC, I would have not know that it was now BitLocker encrypted, or an external disk.

Clicked on Shared_V and immediately got "Windows cannot access \t61\Shared_V".

After lots of playing with this and that, quite a few reboots, connecting and disconnecting the external drives I got lucky!

I had rebooted the box and changed the options under VC's Favorites to have nothing selected, i.e. I un-checked the "Mount selected volume as removable medium". I hit Mount Favorite Volumes and that did the trick - I could see the files remotely again!!!

Now, the question is WHY?

I am sure I used to use that same setup with TrueCrypt (well, it was WinXP and Win7 back then) and the only issue I had found was that I had to go and share the folder every time I rebooted the box as TrueCrypt/Win7 somehow were forgetting the share (not an issue as I had a .bat file to run a few net use commands to share them again).

There was no difference if I was mounting the truecrypt-ed drives as removable medium or not, if they were internal drives or external... at least I don't recall one.

I do prefer to mount removable disks as removable to reduce corruption when the PC crashes or the kids unplug it, or we just have a power outage.

Any chance you could confirm my theory and see if there's a fix?

Thank you again!
Marv
Coordinator
Sep 5, 2015 at 2:17 AM
Hi Marv,

Mounting as removable media is an important information that was missing from your first report. Without it, tests were conducted with the default mount options and that's why I could not reproduce your issue. Every detail counts...

Indeed, now I'm able to reproduce your issue.

In order to check if it is specific to VeraCrypt, I performed the same test using TrueCrypt on Windows 10 and I also have the same error.

The most probable explanation is that Windows 10 is requesting some new unsupported IOCTL from the virtual drive when it is mounted as removable media and since VeraCrypt/TrueCrypt return an error, the sharing fail.

I'll try to discover what IOCTL is causing the issue..this is something that will need a lot of time because it requires using kernel debugging.
Sep 11, 2015 at 11:56 PM
Windows 10 is malware masquerading as an operating system.

http://www.slate.com/articles/technology/bitwise/2015/08/windows_10_privacy_problems_here_s_how_bad_they_are_and_how_to_plug_them.html

http://arstechnica.com/information-technology/2015/08/windows-10-doesnt-offer-much-privacy-by-default-heres-how-to-fix-it/

Considering that Windows 10 is a keylogger and a privacy nightmare, I would like to suggest that using VeraCrypt on Windows 10 is like trying to do sterile surgery inside a sewer. I don't quite understand why we would even try to support VeraCrypt on such an inherently defective foundation.