Thanks for the report. I don't know enough about Windows to understand what is "an account registered in the controller of domain (but local account profile)". But it seems like Chrome could have either trouble accessing the profile directory (listed in chrome://version), or decrypting the login database stored in it.

Chrome encrypts the login database with a Windows method which is associated with the current Windows user account.

Here is my hypothesis:
* Chrome was first run under the local account. It created the login database in the profile path, and encrypted it so that only the local account can decrypt it.
* Then Chrome was run under the other account. It could not decrypt the existing login database, so saving and retrieving passwords could not work.

How you can help confirming the hypothesis:
* Visit chrome://version both when Chrome is run under the local account and under the other account. Do you see the same "Profile Path"?
* Open Chrome under the other account (where saving passwords does not work for you). Add a fresh profile (you can use the steps from https://support.google.com/chrome/answer/2364824, but ignore the parts asking you to sign in). Then go to, say, https://rsolomakhin.github.io/autofill/, and try saving a password in its password form and getting it filled.

If the hypothesis is correct, then this is working as intended. A profile directory should only be used by one OS user. If you want to run Chrome under multiple users, be sure to use separate profiles for them (e.g., by creating a new account as described above).

the user is logged on a domain controller, but the profile is on the local
resource (not on the network). The domain controller is samba 4.2.10.
path to profile in crhome:version
C:\Users\networkuser\AppData\Local\Chromium\User
Data\Default

if i add a profile in chrome, the path:
C:\Users\networkuser\AppData\Local\Chromium\User
Data\Profile 1
Password not saved.

if i add a user to the local windows profile, without registering a domain
controller, the path is C:\Users\localuser\AppData\Local\Chromium\User
Data\Default and the password is saved.
that is, the passwords are stored in folders of local users. If a domain
user, the password is not stored.
rights to the folder C:\Users\networkuser\AppData\Local\Chromium\User Data:
full access networkuser (domain\networkuser)
rights to the folder C:\Users\localuser\AppData\Local\Chromium\User Data:
full access localuser (local_computer\localuser)

I tried to reinstall Chrome, with complete removal of the folder
C:\Users\networkuser\AppData\Local\Chromium\
chromium run from C:\Users\networkuser\AppData\Local\Chromium\bin\chrome.exe
I tried to install Chrome In c:\program files\chromium, the result is the
same.

2017-02-07 0:35 GMT+03:00 v… via monorail <
monorail+v2.3055812653@chromium.org>:

Thank you for the feedback! It proves that my hypotheses from #2 are wrong.

Right now I don't have a good idea about what could be causing this. The team will likely need to reproduce your setting and have a look. I am moving this bug to the team queue.

Can you try to do the following test - run chrome from a command prompt from inside the domain joined user but specify a different profile folder by specifying the --user-data-dir=c:\<somelocalpath> - where is <somelocalpath> writable by that user. 

Also do I understand this right that both for the domain user and the local user the location of their profiles e.g. c:\users\localuser and c:\users\networkuser are stored on a local disk or is the profile folder for the networkuser stored on a network share mounted there?

Key --user-data-dir did not work.

both profiles are stored on the local disk in users folder.

dan.poz71@: What does "an account that is registered in the controller of domain" mean? 

Did you try to remove your local profiles? Perhaps an unrecoverable corruption happened. 

The Windows account takes the password and access rights to the network folders from the samba-server.
in the comment 3 everything is detailed.