NAS Linux based and Google Drive and Acronis True Image
Connected a windows share to a NAS Linux v5 Based Thecus N4100, N5500, N7700, and N8800.
Google Drive reported the directory was not writeable. A quick look and all folders had a black square in read only. Took a look at the security tab and the only full control was for the NAS accounts. All windows account permissions that Google drive relies on were blank and unchangeable. This is by design for Linux NAS permission in Windows. No I cant change everyone to full control..
As google drive has no explicit NAS Linux account the only option was to have the NAS run in public permission mode. Yes google drive now installs.
But it's not a good fix. Acronis True Image Home backup can not log into the NAS. It wants a Linux account to browse despite it being public. But the public NAS has no account! No I can not make a Linux user and get google drive to work.
No its doesnt work!
I thought what you did in that making the account, then authenticating in Acronis to leave it persistently connecting lastly setting the NAS share as public. But it doesn't work. It improves a little as the browse of the directory tree now works in acronis but the previously posted failure screen shot is the backup attempt at using the persistent authtication.
Sompone suggested
This sounds like the old "aligning the Windows and Linux account" problem. As it sounds like a 2 decade old issue I'll keep it short. Why not try the logins aligned. That is if I login on my Windows as Sally, why don't I have a matching Sally account on Linux?
I can't align the logon as I use an email address for windows account sync. What a shame.
Boot IT,
Your issue is I think related to Windows 10 Security fixes for preventing Man in the Middle attacks on remote servers (I presume you are using Windows 10 here).
Please review the attached link below, in particular the Update section covering using Microsoft accounts and/or email address based accounts.
Using such accounts deems such login requests as a Domain user and requries additional authentication which setup of this authentication is outlined in the link:
https://techjourney.net/cannot-connect-to-cifs-smb-samba-network-shares…
I was able to change the registry and now have security for everyone as Full. I tried to follow https://techjourney.net/cannot-connect-to-cifs-smb-samba-network-shares… however the update section can not be followed as the v5 inux NAS does not support Microsoft email adresses as the logon ie hte @ sign is rejected as an error. So I can do backups but not access any files by Google Drive. Now I have found I can't access files using PaperPort pdf products. I imagine many softwares will fail as I use them!
I am unsure how to remove email addresses from the workstations and what problems it wil bring. I have 6 user profile logons based on emails that move between 5 workstations.
Well, Linux/Unix username/password and the Microsoft equivalent do not operate in the same way. These email or Domain username/passowrds are a relative newcomer to the scene. Some applicaitons like skype for example have already embraced the Microsoft account and have made it possible to login to their services using a Microsoft account.
My quess here is that Thecus would need to develope (they may already have) a mapping mechanism that allows a Microsoft account to be mapped to an existing user account on Thecus devices. Have you investigated if Thecus has modified the software and or firmware update that might address this? Thecus may have some other workaround for this as well so I would check with them on this issue.
Support for this particular issue here on this Forum is going to be very limited. I am not an expert on this by any means and can only offer a minimum of solution based advice.
I am not familiar with the Thecus based products so am unsure if you have any access to the Linux shell from which you could attempt manual mapping of an existing Linux account to that of a Microsoft account. Be advised that even if you have or can access the Linux shell the below example of manual mapping may not work as it is dependent on the version of SAMBA installed.
Username mapping Example:
You can add a line in /etc/samba/smbusers:
Code: linux_name = windows_name1, windows_name2 <etc.>
This maps windows name(s) to a linux name. You may also need to add this parameter to the [global] section of: /etc/samba/smb.conf.
Code: username map = /etc/samba/smbusers
You can check if it is necessary to add the above parameter to your smb.conf with:
Code: testparm -vs | grep "username map"
There are two other options to overcome the MSA account allowing me to continue with https://techjourney.net/cannot-connect-to-cifs-smb-samba-network-shares… before User Name Mapping which I think is unsupported on my Thecus NAS. I have tried Option 2 so far.
Option 1.
It was suggested by someone to " Use a local login or create a login script that makes the connection. It's possibly one line long (NET USE) "
I assume they mean to make a bat script from these type of commands
http://ss64.com/nt/net_use.html
Map a drive letter to a remote server/share.
Syntax
NET USE [devicename | *] [\\computername\sharename[\volume] [password | *]]
[/USER:[domainname\]username]
[/USER:[dotted domain name\]username]
[/USER:[username@dotted domain name]
[/SMARTCARD] [/SAVECRED] [[/DELETE] | [/PERSISTENT:{YES | NO}]]
Map to the current user's home directory as specified in the users Active Directory record:
NET USE {devicename | *} [password | *] /HOME
Set defaults:
NET USE [/PERSISTENT:{YES | NO}]
Option 2.
How to Disable Windows 10 Email Login
https://www.infopackets.com/news/9650/how-disable-windows-10-email-login
To login with a local account and disable the Windows 10 email login, do the following:
Click Start and type in "user accounts" (no quotes); click the User Accounts icon that appears in the list.
OPTIONAL: If you are signed on as the Administrator user, click the "manage another account" link. Then select the account you want to change.
Your user account will be displayed with the title "Make changes to your user account". Directly underneath that heading there is a link that says "Make changes to my account in PC Settings"; click that link.
If you don't see the "Make changes to my account in PC Settings" link, then do this instead: click Start, type in "change your account" and wait for "Change your account picture or profile settings", and click that link. Proceed to the next step.
The "Settings" app will now open a new window. Click on the "Your email and accounts" heading on the left.
Next, click the link that says: "Sign in with a local account instead".
Enter your password on the proceeding page and click Next.
Enter your new user name, password, and password hint, and click Next.
On the proceeding page, click "Sign out and finish" and you will be taken to the login screen where you can login using your local account.
All of this can be reversed if needed -- the only difference is that in Step 4 you would click on a link that says "Sign in with a Microsoft account instead". It's also worth noting that you can assign your Microsoft Account login to any local account at any time.
Result
I am now using a local login nothing has changed despite the login alligned with the Linux NAS.
Acronis True Image Backup only works when using non public credentialed share. That stops Google Drive.
The google account only works when using a public share. That stop Acronis.
What is rather strange is that a post from google says some shares are not supported for google drive.
https://support.google.com/a/answer/2490101?hl=en
"Google Drive for Mac/PC supports only HFS+ (on OS X) and NTFS (on Windows) file systems. There's currently no support for network volumes (e.g. SMB or NFS) or other file systems, such as FAT32."
I cant work out how the google drive works on my Linux NAS when the share is public. It uses SAMBA by default so it should not work at all unless Google drive has updated to supporting this since the google support post.
I do not use a Microsoft account, do not use Google Drive either but, I believe you are wrestling with Windows 10 new Security policy here. Unathenticated public account access is not allowed in Windows 10 to/from a remote server to the best of my knowledge. Your attempt at usage of such an account thus fails. Your attempt at usage of the Microsoft account deems that account as a Domain requiring additional authentication. Providing that authentication is what is needed to fix the issue in my opinion. The alternatve is to edit Group Policy to assign all users to a group having access to the share and even then I think the public non authenticated account will not work.
I'll see if I can test connectivity to a public share on my WD-Mycloud from both Windows and Acronis later tonight - might help verify if this is default behavior in Windows 10 or not.
I don't see how a Microsoft account would prevent/limit access to a NAS share as you would be entering credentials for the share on the NAS itself. This could be an issue for a remote share on another Windows PC though, but a NAS, I don't see it. I log into Windows with my Microsoft account now and connet to my NAS using the account informaiton that is created from the NAS side.
The other "gotcha" could be if you have other shares to the NAS that do have credentials since Windows does limit authentication to a remote SMB device to just one user authentication session per each Windows logon (at a time).
I'm finding that if you have a mapped drive with saved Windows credentials - that's one session right there. I imagine the same to be true even if the mapp drived is public/open and is allowed to connet in Windows 10.
Likewise, instead of a mapped drive, if you have saved credentials in windows crednetial manager for a network share that is not mapped, it creates the same limiation for subsequent connections.
And, another culprit I found in my setup was another backup product that automatically connects a hidden "net use" connection to my NAS from the perviuos credentials I used when I setup a test backup with it. Never knew it was there until I started doing some digging on my machine when I kept getting access denied to my normal NAS shares in both Acronis and Windows file explorer as a result since I had used a different NAS share and different NAS account for my test with this other backup product.
Corrupting SMB share authentication seems to be something unusual that may change the direction this problem is travelling. I do appreciate the help so far.
I cleared credential manager on the workstation. I changed the passwords on the two NAS. I cleared the shares and checked on NET USE for any other connections. I logged into the workstation using the same logon as the NAS share user I changed the password on.
As expected both NAS shares requested the logon and password which I entered in windows however I did not click remember to ensure they would reset after signing out.
I logged into Acronis and set up a backup. Likewise as expected both NAS shares requested the logon and password which I entered in Acronis. I ran the backup.
I logged out of windows and logged back in.
As expected both NAS shares requested the logon and password which I DID NOT ENTER in windows.
I logged into Acronis and set up a second backup. This time both NAS shares DID NOT request the logon and password and appeared to remember the one which I entered in Acronis in the last session. I ran the backups successfully. Windows and Acronis appear to have an independent authentication database.
About 8 hours later I logged into Acronis and set up a third backup. This time both NAS shares requested the logon and password which I entered in Acronis. They had a connection error.
Credential manager was still clear on the workstation. The shares were still not remembered and I checked on NET USE for any other connections. I changed the passwords on the two NAS. I logged out to use them.
I logged into the workstation using the same logon as the NAS share user I changed the password on.
As expected both NAS shares requested the logon and latest password which I DID NOT ENTER in windows.
I logged into Acronis and set up that third backup. Likewise as expected both NAS shares requested the logon and password which I entered in Acronis. I ran the backup successfully.
I wonder why Acronis is corrupting its password system.
As for google drive I found I could install on the NAS when in public mode. When I switched to private with a password, it would work as long as the share was authenticated. If a password change occurs, it would report lost google drive directory. One authenticated with a log out and in it would sync.
I know that windows keeps remembered SMB share information successfully if I tick remember. Its Acronis that is corrupting.
Where the problem was occuring with Google Drive was that Acronis password changes due to the corruption were causing the shares to be reset by me and google drive looked like it was failing. However all it was doing was patiently waiting for me to log out and in with an authenticated share but I kept changing things.
So is this the problem; is Acronis corrupting its password system? Is the corruption specific to the SMB share environment?
Boot IT,
Great piece of investigative work there. If you would, please submit feedback with reference to this thread to Acronis.
I have not experienced this corruption of passwords as you put it but seems you do have problem with that. At least you understand the problem now and have a way to work around it.
I set up a support incident Case ID: 02811916
Thanks for your help
BootIT...let me add my thanks for your excellent investigative analysis. I have also experienced this same "problem" and reported it directly to Acronis...their response was that they could not duplicate this problem.
ATI 2017 stores credentials independent of Windows credentials. Credentials for the backup are stored in the script file for the backup. So, once the backup is up and running, it should continue to run, unless you change the NAS login credentials.
When setting up a backup, or accessing the NAS through the ATI 2017 UI, ATI uses (and stores) the credentials in the Windows registry at:
HKEY_CURRENT_USER\SOFTWARE\Acronis\Connections\smb\YourNASName
This is where the credentials "corruption" is occurring (on my computer).
Regards,
FtrPilot
Something I think could be at work here is this. I am not sure how True Image stores path to backups but it is possible I think that if the user has DHCP enabled that could be an issue and is possibly at root of this seemingly unsolvable problem. A change to a static IP address may just fix the issue.
As I have stated before I do not have this issue on my network. I run a mix of DHCP and static IP's on my network. My NAS machine has a static IP address assigned by default. My WD MyBook external drive has a static IP address as well because it is attached to my router. My client machines use DHCP. Not sure about other users, how they are setup, but someting to look at I think!
I don't think there is any password corruption occurring. There is a long post of new (bad) behavior with NAS connectivity when you attempt to edit an existing NAS connection or create a new one IF YOU HAVE A MAPPED DRIVE in Windows already (any chance you're using mapped drives in Windows too - if so this may be the true culprit). As far as I can tell, this is a bug and definitely needs to be addressed.
However, there are work-a-rounds, but definitely does not seem to be working as it should be. If you have mapped Windows drives in Windows to the NAS, try temporarily disabling them, then launch Acronis and create your new backup task to your NAS share or edit your existing back task - hopefully it authenticates now.
Once all is configured in Acronis and successfully connected, then you can go back and map the drives in Windows again. If you try to edit Acronis again, it will fail during the authentication part, but backup should still be able to connect and run. Not ideal, but should do-able in the interim until a fix is released.
https://forum.acronis.com/forum/126528?page=1#comment-395276