Login gives error - Can't create /home/username/* on Linux Mint 17.2
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Originally Posted by af7567
Does the encrypted home option use your login password as your encryption password too? If so it sounds like your encrypted home is using your typoed password but your account is using the new password you set from the root shell, so they are out of sync.
that is a design issue then. Because it sould not matter reguardless by what method you used to change your password, because only you or root user can do this. For it not to sync, to me, is a malfunction within the design of said distro.
I do not use encription so that is an at first glance option.
I tried the below. It did manage to mount the private files, but their still encrypted
Code:
mint@mint ~ $ sudo ecryptfs-recover-private
INFO: Searching for encrypted private directories (this might take a while)...
INFO: Found [/media/mint/34e5c4fa-0621-46cb-83b0-763c2a0dc49c/home/.ecryptfs/tijmen/.Private].
Try to recover this directory? [Y/n]: y
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] y
INFO: Enter your LOGIN passphrase...
Passphrase:
Error: Unwrapping passphrase and inserting into the user session keyring failed [-5]
Info: Check the system log for more information from libecryptfs
mint@mint ~ $ sudo ecryptfs-recover-private
INFO: Searching for encrypted private directories (this might take a while)...
INFO: Found [/media/mint/34e5c4fa-0621-46cb-83b0-763c2a0dc49c/home/.ecryptfs/tijmen/.Private].
Try to recover this directory? [Y/n]: y
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] n
INFO: To recover this directory, you MUST have your original MOUNT passphrase.
INFO: When you first setup your encrypted private directory, you were told to record
INFO: your MOUNT passphrase.
INFO: It should be 32 characters long, consisting of [0-9] and [a-f].
Enter your MOUNT passphrase:
INFO: Success! Private data mounted at [/tmp/ecryptfs.cQtlJNMc].
mint@mint ~ $
that is a design issue then. Because it sould not matter reguardless by what method you used to change your password, because only you or root user can do this. For it not to sync, to me, is a malfunction within the design of said distro.
I do not use encription so that is an at first glance option.
I can see why they did this; otherwise anyone with access to the computer and a little knowledge of linux could easily use root to change the password and gain access. That's the trouble with encryption: it's either convenient and user friendly, or as safe as possible. Never both.
I can see why they did this; otherwise anyone with access to the computer and a little knowledge of linux could easily use root to change the password and gain access. That's the trouble with encryption: it's either convenient and user friendly, or as safe as possible. Never both.
yeah I too can see it with distros like mint or Ubuntututu that give a user a backdoor to root, because they do not actually give the user a front door. so the backdoor no password needed for root is what they have to use instead. because you cannot actually get rid of root
that is more a security issue then allowing a user to put a root user password in, and creating a actual root user account.
that too is another reason I stay away from distros that do not give the user a root account. It is a necessity.
one can just switch tty's and they still have to know the root passwd to get in. but them that do,are mostly the person that owns it and is acutally the root user with another user account. that is the way it should be.
then he can do as he did change passwords. being that it was an actual root account that it'd be done in. Then I wonder if that sync would have still failed? because it was not done in an passwordless root shell crap that any one can use.
yeah I too can see it with distros like mint or Ubuntututu that give a user a backdoor to root, because they do not actually give the user a front door. so the backdoor no password needed for root is what they hae to use instead. because you cannot actually get rid of root
that is more a security issue then allowing a user to put a root user password in, and creating a actual root user.
that too is another reason I stay away from distros that do not give the user a root account. It is a nessessity.
one can just switch tty's and they still have to know the root passwd to get in. but the that do, mostly the person that owns it is acutally the root user with another user account. then he can do as he did change passwords. being that it was an actual root account that it'd be done in. Then I wonder if that sync would hae still failed? because it was not done in an passwordless root shell crap that any one can use.
Correct that's a major issue, which seems like it could have easily been avoided.
Anyway, the mount passphrase is a 32 character phrase made up from a-z and 0-9, so brute forcing it isn't really an option either. I'm off back to DuckDuckGo, to see what else I can find. Thanks for all your help so far
Correct that's a major issue, which seems like it could have easily been avoided.
Anyway, the mount passphrase is a 32 character phrase made up from a-z and 0-9, so brute forcing it isn't really an option either. I'm off back to DuckDuckGo, to see what else I can find. Thanks for all your help so far
there use to be a really good website called 'hackers.com' with all kinds of useful tools hehehe
I just checked and its no longer up
hehehe, thanks for those. Unfortunately, my passwords are highly secure against attacks like those outlined in these articles. Again, it's my own security measures horribly backfiring..
how to recover wrapped-passphrase????
read towards the bottom of this page I think this person recovered his wrapped-passphrase. He got his stuff back
read
post #5,and 6
I have no idea of what I am doing in how this actually works but this might help.
Thanks for that. unfortunately, that approach gave no result either.
Code:
mint@mint ~ $ ecryptfs-unwrap-passphrase /media/mint/34e5c4fa-0621-46cb-83b0-763c2a0dc49c/home/.ecryptfs/tijmen/.Private/.ecryptfs/wrapped-passphrase
Passphrase:
Error: Unwrapping passphrase failed [-13]
Info: Check the system log for more information from libecryptfs
The below is from my syslog. This seems to happen consistently when I try to access the encrypted folder
Code:
Feb 24 00:34:49 tijmen-desktop atieventsd[2247]: ATI External Events Daemon started...
Feb 24 00:34:49 tijmen-desktop atieventsd[2247]: Event daemon control socket created
Feb 24 00:34:49 tijmen-desktop atieventsd[2247]: acpid connection established
Feb 24 00:34:49 tijmen-desktop acpid: client connected from 2247[0:0]
Feb 24 00:34:49 tijmen-desktop acpid: 1 client rule loaded
Feb 24 00:34:49 tijmen-desktop kernel: [ 69.661985] init: plymouth-stop pre-start process (2306) terminated with status 1
Feb 24 00:35:10 tijmen-desktop mdm[2313]: pam_ecryptfs: Passphrase file wrapped
Feb 24 00:35:10 tijmen-desktop mdm[2313]: Incorrect wrapping key for file [/home/tijmen/.ecryptfs/wrapped-passphrase]
either the correct key got screwed up somehow or you're using the wrong key... that is what I'd access from that information. Then I'd attept the proper actions that would hopefully remove said error.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.