I installed Cygwin on USB stick. I'm going to use Cygwin on two computers. (My laptop and a desktop computer.)
Unfortunately, those two computer have a different user name. (user and ryang). So every time I switch those two computers, the location of user's home directory chages.
If I use Cygwin with ryang, the home directory is /home/ryang. If I use Cygwin with user, the home directory is in /home/user. But I want to use only one user, "sohnryang".
I don't want to change those two computer's settings. Any good solution for this?
The problem is not just that the two users are different for Cygwin, they are also different from Windows point of view.
To rename a cygwin user you can use the file /etc/passwd
mkpasswd -c > /etc/passwd
sed -e "s/ryang:/sohnryang:/g" -i /etc/passwd
and you can repeat it in the second computer
mkpasswd -c >> /etc/passwd
sed -e "s/user:/sohnryang:/g" -i /etc/passwd
so now both will share the same cygwin name.
The : is needed to change only the first and sixth fields; leaving untouched the fifth.
However the two users are different also for Windows as you can verify with
C:\Users\myself>whoami /user
USER INFORMATION
----------------
User Name SID
==================== =============================================
my_computer\myself S-1-5-21-531030479-1339336681-3415091201-1009
The two SID's are different in the two computer also if the user names were the same in Windows.
The Windows User Name and SID are merged in the 5th field of /etc/passwd
The SID difference could cause authorization issue between files created on the two computer, depending on the type of system. Windows Home versions are usually more puzzling than Professional ones.
Another quick solution -- if you are the only Cygwin user on each machine -- is to edit the file /etc/nsswitch.conf and set db_home to the desired home directory location:
db_home: /home/MyName
This does not actually change the user name itself. If the directory is hardcoded in this manner, ALL users who log in to Cygwin will be set to use this same directory. But for single-user systems, it's quick, easy, and works like a charm.
Related
I'm currently practicing basic Shell Commands in WSL, Windows Subsystem for Linux (I do not have a linux system but I want to get familiar with commands).
I start a bash session on the command prompt window and navigate to my desktop using cd . In desktop I noticed that after using ls -lF some files with the prefix ~$ appear, such as: '~$executable.x'* or '~$file.txt'
These files are not currently present under the desktop directory, but I was able to remember that they were at one point (varying from a week to months ago).
When I do the same process in powershell windows (not using linux commands) I noticed that files displayed match the desktop and no extra files are listed.
I was wondering if anyone could explain what ~$ means in this context? my intuition is telling me they are backed up files that are somehow hidden in the desktop. After googling, all I could find is that ~ reefers to the home. I also understand that $ is the default prompt symbol for the bash shell when it is waiting for me to type something, but I'm still confused on why it would show up as a prefix for the name of a file.
Hope I made my question clear.
I'm currently reading "Linux® Command Line and Shell Scripting BIBLE" by Blum and Bresnahan but I could not find an answer there, this is my last resource after many googling attempts. Any other source for more information on the topic would be helpful.
On Windows, files that start with ~ are used for hidden files. More specifically,, the prefix ~$ are often used as backups for programs, should they crash before writing updates to a file (e.g. Microsoft Word, etc.)
From Wikipedia:
The tilde symbol is used to prefix hidden temporary files that are created when a document is opened in Windows. For example, when you open a Word document called “Document1.doc,” a file called “~$cument1.doc” is created in the same directory. This file contains information about which user has the file open, to prevent multiple users from attempting to change a document at the same time.
See: Why does Word make temporary files?
Relevant superuser question: https://superuser.com/questions/405257/what-type-of-file-is-file
I've set up WSL (Windows Subsystem for Linux) on my Windows 10 to utilize Bash. I've created a Linux user, installed the latest updates and upgrades, and I know how to access the Windows files through /mnt/c/Users etc. When I try to create a new file on my desktop, it denies permission:
rupert#DESKTOP-GT4APR9:/mnt/c/Users/zolta/OneDrive/Desktop$ touch
file.txt touch: cannot touch 'file.txt': Permission denied
How can I grant my Linux Bash user permission to create and modify files and directories on my Windows user desktop? Is that possible at all?
I would use sudo, i.e. sudo touch file.txt. Works for me in WSL2 Ubuntu (which is Debian based)
The path with which you are having problems,
rupert#DESKTOP-GT4APR9:/mnt/c/Users/zolta/OneDrive/Desktop
appears to live on OneDrive: While I am not a OneDrive expert, my understanding is that to access it from the command line, the remote data stored on OneDrive has to synced locally.
If you cd rupert#DESKTOP-GT4APR9:/mnt/c/Users/zolta, can you touch file.txt there?
What about accessing these folders from cmd or pwsh?
By default, on a brand new Windows 10 install, the user sub-directories (Desktop, Documents, etc...) are located within the OneDrive directory, inside the home directory (that is troublesome in my opinion).
It will allow synchronisation between devices.
I do not know if WSL is able to access such a directory, like it cannot access USB storage for exemple.
You may want to ls first in order to see if you can access:
ls -alh /mnt/c/Users/zolta/OneDrive/Desktop
If you can see your files, that is a write access issue. You might correct it by changing the owner or the directory and it's content:
sudo chown -R $USER:$USER /mnt/c/Users/zolta/OneDrive/Desktop
If you cannot, try using sudo:
sudo ls -alh /mnt/c/Users/zolta/OneDrive/Desktop
If nothing can be seen, or an error raise, that probably means WSL cannot access this directory.
In that case, I suggest you change default directory as stated in the Microsoft documentation.
I have created two new users in my FreeBSD unix environment and I want to limit their access to their respective home directories only.
After reading on the internet, I found a solution to modify /etc/passwd file and change their bash to rbash which will prevent them to run CD command.
so I run the following command to find where my rbash is ?
where rbash
and it gives the following output,
usr/local/bin/rbash
so I opened my /etc/passwd file and change the /bin/sh to /usr/local/bin/rbash.
After that I logged out and logged back in using the account for which I modified the settings but I could still run the CD command, or any other command for that matter.
Can anyone please tell me why it is not working ?
Can this be done using Samba or any other solution ?
There is a Mac on our network (let's call it MACHINE) that is configured to do LDAP authentication. There is no local user named USER on this Mac, but there is a user named USER known to the LDAP server.
When I execute this command from my Mac:
ssh USER#MACHINE echo \$PATH
where is that path being loaded from?
(notice the path I get that way is quite different from if I do the ssh, open a remote session, and then type echo $PATH)
There are a lot of places that the path isn't being loaded from (I know this because they specify paths that don't appear in the actual \$PATH):
/etc/paths
/etc/paths.d
/etc/bashrc
Thanks,
Chris
There is usually a template user account provided by a Unix'y system, and I am pretty sure it will include a path in it. Usually that would be etc/skel.
On the Mac it is:
/System/Library/User\ Template/
I need to write a OS X login hook script that is aware of the users current home folder. Since the users are Active Directory users, their home folders are not stored in /Users so I can't simply hard code the full path.
Since the login hook is run by a daemon as root, I can not use $HOME, ~, etc either.
The only piece of info I have is the users name which is passed in as an argument to the script.
Is there any way to resolve the users home folder given all these restraints? The script does not need to be a login hook necessarily, but it does need to run for all AD users that log into the machine.
It turns out this command works great:
finger $USER_NAME | grep Directory | expand | cut -d ' ' -f 2
The expand is needed because if the folder path is long, finger will use a tab to separate the fields instead of a space.
Try:
dirt -u username -n
dsconfigad -show
Further reference:
http://www.mactech.com/articles/mactech/Vol.20/20.11/ActiveDirectory/index.html