Welcome to My WebPage "Ubuntu / Kubuntu"![]()
| HOME CONTACT UBUNTU LINUX WINDOWS MOZILLA SOFTWARE COMPUTER TIPS ARTICLES SIGNS & BANNERS TROUBLESHOOTING WINDOWS |
KUBUNTU
Page [ 2 ]
Access and Mounting Shares in Windows Vista and Linux
First problem I ran into was that the Vista machine couldn’t access shared resources on the Linux box and vice versa. I had no problem passing files back and forth between the Linux box and one running Windows XP. This post deals with the first problem, connecting to the shared resources on the Linux box. (I’ll tackle the issue of connecting to a Vista share in a follow-up post.)
There are two possible reasons why a Vista user can’t connect to a Linux share:
1. Windows Vista changes the authentication method for password-protected shares. In XP and previous versions, the system by default used two password hashes, the old-style LAN Manager (LM) and the newer NTLM version 2 (NTLMv2). (If you want the gory details, read this excellent article
( https://www.microsoft.com/technet/technetmag/issues/2006/08/SecurityWatch/?topics=y ) by Windows security guru Jesper Johansson. Although it was written using a beta version of Vista, the information is still accurate.) Older versions of the Samba server in Linux use only the LM hash, which means they have no trouble connecting to a default installation of XP but will fail when trying to talk to a default installation of Vista.
To fix this problem, you need to update the version of Samba on the Linux machine to 3.0.22 or higher. (If you’re using an earlier Samba version, you can downgrade Vista’s authentication to accept LM hashes, using either Local Security Policy Manager or a registry edit. I don’t recommend this option.)
2. Challenge #2 was to get Samba configured on the Ubuntu Linux machine. In my case, the samba-common package was installed and was at the correct revision (3.0.22–1), but the samba package itself was missing. (Update: On a second machine when I tried a clean install, smbfs was missing as well, and I was unsuccessful until I installed it.) After I installed the missing pieces, I had one more step to run through. From a Terminal window, I needed to add a Samba user and password. Windows users are accustomed to having file sharing and authentication handled using the credentials for their user account, but with a Samba server the databases are different. The syntax, in my case, was fairly straightforward:
sudo smbpasswd -a username
In this command, username is the same as my account name. You can create an account for another user as long as they already exist in the user account database.
(Note
that you have to respond to three password prompts at this point. The first is
for the root password of the logged-on user, and the next two set
the SMB password for the user whose account you’re adding.)
After going through these steps, I was able to access shared folders on the Linux machine.
Changes in the architecture of Windows Vista make it more difficult to connect to Vista shares from Linux machines. If you browse the network from Linux (network:///), you can see other machines, including those running any version of Windows. If you double-click the icon for a computer running Windows XP, you can see a list of shared resources on that computer. You can also connect to those resources if you have the correct password. But if you try the same thing with a computer running Windows Vista, you’ll find yourself unable to view the shares, much less connect to them.
Fortunately, there are a couple of workarounds.
For quick access to a shared folder on a machine running Windows Vista, first create an empty folder in your Home directory, using a name that describes the shared files. Next, open a Terminal window and enter the following command, all on one line:
sudo mount -t smbfs -o username=windows_username,password=windows_password
//vista_pc_name/share_name
mount_folder_name
Substitute your Windows username and password for the values in red. Use the UNC path for the Windows share, and replace mount_folder_name with the full path of the folder you created (in my case, I created a folder called shared_vista, so the path I used was /home/edbott/shared_vista). Be sure not to add a space after the comma and before the word password.
This technique works fine for quick access to shared files on a Vista machine, but there are two limitations. First, the mounted folder isn’t persistent. If you restart your machine, you’ll have to execute the mount command again to gain access to those shared files. Second, access to the Vista folder is read-only. That’s fine if you just want to copy some files from your Vista machine to the Linux box, but it’s a nuisance if you want to go the other direction.
In the last installment of this series I showed how to quickly mount a shared folder on a Windows Vista machine from a Linux machine (specifically, from one running Ubuntu 6.10). This solution works if you just want to read files on the Vista PC and you don’t mind re-entering the mount command the next time you reboot your Linux PC. But what if you want the Vista shared folder to be permanently available to all users, in read-write mode?
Here’s how. As in the previous post, these instructions assume that you’ve set up a password-protected shared folder on the Vista machine in a non-domain environment, that you have already installed Samba server v3.0.22 or later and smbfs on the Linux machine, and that you’ve created a Samba user account and password. (For details on how to perform these last two tasks, see Vista Hands On #13: Connect to a shared folder on a Linux machine.) All of the following steps are performed on the Linux machine.
1. Choose a name to use for the shared folder on your Linux machine, such as vista_public. Open a Terminal window and issue the command sudo mkdir /mnt/vista_public (if you chose a different name to identify the shared folder, substitute it for vista_public). This creates a directory that will be used as the mount point for your shared folder.
2. Using a text editor, create a plain text file containing two lines:
username=windows_username
password=windows_password
Substitute your actual Windows username and password for the italicized text. Save the file in your home folder as .smbpasswd (don’t forget the dot at the beginning of the filename, which makes the file hidden). Finally, change the permissions on the file so only you can open and change it by issuing the following command in a Terminal window:
chmod 600 .smbpasswd
3. On the Linux machine, open /etc/fstab in a text editor. (On Ubuntu, I used the command sudo gedit /etc/fstab. You can use another editor if you prefer.)
4. At the end of the file, add a new line containing the following:
//vista_pc_name/share_name mount_folder_name smbfs credentials=/home/linux_username/.smbpasswd,uid=linux_username,gid=users 0 0
Use the UNC path for the Windows share, and replace mount_folder_name with the full path of the folder you created in Step 1 (in this example, /mnt/vista_public). Substitute your Linux username for the values in red. These credentials will be passed to the Vista machine. (Note: there’s no space after the comma and before the uid and gid.) [Update: Thanks to Jeremy Allison in the comments of the previous post for pointing out that smbfs is deprecated and no longer maintained. You can safely substitute cifs for smbfs in the fstab entry.]
5. Save the file and, in the Terminal window, issue the command sudo mount -a.
6. Create a link in your Home folder or on the desktop to the location you created in Step 1 (in this example, /mnt/vista_public) and give the link a descriptive name. Click OK to save it.
You now have a shortcut (link, in Linux-speak) that you can use to to access files in your shared Vista folder. If you find that subfolders in the shared folder are set as read-only, right-click the folder on the Linux box, choose Properties, and click the Permissions tab.
To mount
an smbfs share from a Linux workstation at the command line, you can use either
the
smbmount
command or use
mount -t smbfs.
Both command will work the same. When you use
mount -t
smbfs, the mount program actually
passes the command over to
smbmount
for execution. Throughout this document I'll use
smbmount
instead of mount -t smbfs.
An example would look like this:
smbmount //servername/sharename /mountdirectory -o username=mywindowsusername,password=mywindowspasswordThe
mount
equivelant is:
mount -t smbfs //servername/sharename /mountdirectory -o username=mywindowsusername,password=mywindowspassword
//servername/sharename
refers to the name of the Windows computer and the name of the share.
/mountdirectory
refers to the directory you use as the mount point on the Linux workstation. It
can be any directory as long as the user executing the command has rights to it.
Whether you need to supply a username and password depends on what type of security you have on the Windows share. If you have a share created with no password on it, you shouldn't need to provide a username and password. If the share happens to be on a Windows NT server that is part of a domain, you would need to provide a domain login name and password.
smbmount does not make the mount permanent. If the Linux workstation is rebooted, you will have to mount the share again. To make the mount occur each time you start the Linux workstation, you can put an entry in your /etc/fstab file. An example file would look like this:
LABEL=/ / ext3 defaults 1 1LABEL=/boot /boot ext3 defaults 1 2none /dev/pts devpts gid=5,mode=620 0 0LABEL=/home /home ext3 defaults 1 2none /proc proc defaults 0 0none /dev/shm tmpfs defaults 0 0/dev/hda3 swap swap defaults 0 0/dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0/dev/hdd4 /mnt/zip100.0 auto noauto,owner,kudzu 0 0/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0//servername/sharename /mountdirectory smbfs username=windowsuserename,password=windowspassword 0 0
The last line in the file is the line that will mount the Windows share. You would add a line similar to that in your /etc/fstab file for each share you want to mount. Once again the username and password are only needed if the Windows share is set up to require them. If a username and password are not required, you may just replace them with the word defaults.
An important thing to remember is that there is no space between the comma and the word password. If you put a space there, it won't work.
The /etc/fstab is readable by everyone so it obviously wouldn't be a good idea to have your Windows password in it. The way to get around this is by using what is known as a credentials file. This is a file that contains just the username and password. The best place to put this file would be in your home directory. Here is how to do it.
Create a file in your home directory named .smbpasswd (the period at the start of the filename makes it a hidden file). Modifify the permissions on the file so only you have permission to read and write to it. The only thing in the file is your Windows username and password. Here's the commands you would enter to create the credentials file:
cdecho username=mywindowsusername > .smbpasswdecho password=mywindowspassword >> .smbpasswdchmod 600 .smbpasswd
Substitute your Windows username and password in the commands. No one else except root would be able to read the contents of this file.
Once that is created, you would modify the line in the /etc/fstab file to look like this:
//servername/sharename /mountdirectory smbfs credentials=/home/myhomedirectory/.smbpasswd 0 0
You can
also use the credentials option in the
smbmount
command for security reasons. That command would look like this:
smbmount //servername/sharename /mountdirectory -o credentials=/home/myhomedirectory/.smbpasswd
Providing Read/Write Access to the Share
Another problem with mounting the Windows share as shown in the /etc/fstab file above is that only the root user would have read/write access to the share. All other users would have read only access to it. If you wanted read/write access to it for yourself, you need to specify your userid or groupid. That would change the line in /etc/fstab to look like this:
//servername/sharename /mountdirectory smbfs credentials=/home/myhomedirectory/. smbpasswd,uid=mylinuxusername,gid=mylinuxgroupname 0 0
Whatever user and or group you specified in the line would have read/write access to the mounted share. You can use either the user or group name or the user or group numerical ID. Either should work.
If you had several users you wanted to have read/write access to it, create a group and add those users to the group. Then specify just that groupid in the /etc/fstab file. You wouldn't need to specify a userid. The line in etc/fstab would look like this:
//servername/sharename /mountdirectory smbfs credentials=/home/myhomedirectory/. smbpasswd,gid=sambausersgroup 0 0
You can
see the
man
pages on
smbmount,
smbumount,
mount,
and
fstab
for more details.
Troubleshooting
If you have trouble mounting your Windows shares from /etc/fstab, here are some things to try.
The most
important thing is to try to mount the share using the
mount -t smbfs
command from the command line. This is what will be executed when the the Linux
workstation is booted up and the mounts in /etc/fstab are initialized. If you
can't sucessfully mount the share with
mount -t smbfs,
it won't work in /etc/fstab. Work the bugs out with
mount -t
smbfs. Once it works, it should
then work in /etc/fstab.
One of
the most common problems with
mount -t smbfs
is a file not found error. The file not found is smbmnt, which is used by
smbmount.
It's usually a result of the
smbmnt
command not being in the path when the
mount
command executes. The
mount
command usually resides in the /bin directory and smbmnt resides in /usr/bin. To
fix this problem, you need to create links to smbmnt in the /bin directory. To
accomplish this, execute these commands as root:
ln -s /usr/bin/smbmnt /bin/smbmntln -s /usr/bin/smbmount /bin/smbmount
Another
problem occurs when a non-root user tries to mount a Windows share using
smbmount.
To allow them to do it you need to setuid root the
smbmnt
command. Since
smbmnt
usually resides in /usr/bin, you can accomplish it with this command as root:
chmod u+s /usr/bin/smbmnt
This will
not work if you setuid the
smbmount
command. It is specifically written so that it won't execute if it is setuid
root.
To allow
non-root users to unmount the shares, you need to setuid the
smbumount
command. Execute this as root:
chmod u+s /usr/bin/smbumount
Kubuntu
Once installed instead of restarting turn off the computer and eject CD before it boots up
Install all updates before using and doing anything else
To change your desktop from Ubuntu (GNOME) to Kubuntu (KDE)
In Terminal
Sudo apt-get install kubuntu-desktop
select kdm as dm
sudo apt-get remove ubuntu-desktop
sudo apt-get autoremove
To install alien for installing rpm packages
sudo apt-get install alien
sudo alien -k name of the rpm file.rpm
In the folder containing the rpm file using terminal
alien -k name of the rpm file.rpm
If on your desktop using terminal
alien -k /home/your username/desktop/name of
the rpm file.rpm
You can install alien itself from the Ubuntu Universe repository by adding the repository to your list of sources and doing:
$sudo
apt-get update
$sudo apt-get install alien
Installing the .rpm fileTo
install the .rpm file, you first need to convert it to a .deb file which can be
installed on Ubuntu.
I assume that you downloaded the package to your Desktop (~/Desktop is the
directory)
You can convert the .rpm to a .deb by using the following commands.
$cd
~/Desktop
-This will change the directory to your desktop, where you have the .rpm file.
$sudo alien -k name-of-rpm-file.rpm
- This will convert the .rpm to a .deb.
- The “-k” will keep the version number. Otherwise alien adds a “1″ to the
version number.
- Tip: Use
Smart Tab Completion to avoid mistyping the file names ![]()
$sudo dpkg -i name-of-deb-file.deb
- This will install the .deb package
Try reading the alien manpage for more details on how to convert other kinds of packages and the options available.
The Bash shell has this sweet feature where
you can use the TAB key to auto-complete certain things. For example, when I am
in my home directory, the following command:
$cd Do[TAB-key]
will automatically yield:
$cd Documents
download the
tarball
change direcectory to the directory of the tarball and untar it
cd /path/to/tarballs/directory
to untar a .tar file
tar xvf filename.tar
to untar and ungzip a tar.gz or .tgz file
tar zxvf filename.tar.gz
to untar and unbzip a tar.bz2 file
tar jxvf filename.tar.bz2
the tarball will extract into the current directory, usually making a new
direcory with the contents of the tarball in it....cd into the directory the
tarball extracted to.
Generally, this is not absolute, but generally from here you will
./configure
make
make install
If you
are an absolute novice, like I was, not so long ago, discovering tab completion
in the terminal can make you go “Wow!”. Wait till you hear the rest now
Though
you can use the TAB key to complete the names of files and directories, by
default the completion is pretty “dumb”. If you have already typed
$cd D
you would expect that the tab key would cause only the directory names to be
completed, but if I try it on my machine, the tab completion tool uses filenames
too.
Now, don’t despair! There is now a smart bash tab completion trick you can use. Smart completion even complete the arguments to commands!!
To enable
smart completion, edit your
/etc/bash.bashrc
file. Uncomment the following lines, by removing the # in the beginning of the
lines:
#if [ -f /etc/bash_completion ]; then
#
. /etc/bash_completion
#fi
Now you can use tab completion to power your way through commands.
You can even extend bash smart completion to your own favourite commands by using /etc/bash_completion, the “complete” utility and /etc/bash_completion.d . Explaining the nitty-gritty is beyond me. I refer you to the Debian Administration gurus for more information regarding smarter bash completion.
How to
install & use .rpm to .deb Converter (Alien)sudo aptitude install aliensudo alien -d package.rpm (-d for Debian package)
sudo aptitude install checkinstall
· When compiling software from source, replace "make install" with "checkinstall"
./configuremakecheckinstall
A Debian package (.deb) will now be created in the current directory.
· To install the created package
sudo dpkg -i package_name.deb
·
RootSudo
In Linux (and Unix in general), there is a
superuser named root. The Windows analog of root is Administrator. The superuser
can do anything and everything, and thus doing daily work as the superuser can
be dangerous. You could type a command incorrectly and crash the system.
Ideally, you run as a user that has only the privileges needed for the task at
hand. In some cases, this is necessarily root, but most of the time it is a
regular user.
By default, the root account is locked in Ubuntu. This means you cannot login as root or use su. Instead, the installer will setup sudo to allow the user that is created during install to run all administrative commands.
This means that in the terminal you can use sudo for commands that require root privileges. All programs in the menu will use a graphical sudo to prompt for a password. When sudo asks for a password, it needs YOUR USER Password; this means that a root password is not needed.
· The password is stored by default for 15 minutes. After that time, you will need to enter your password again.
· Your password will not be shown on the screen as you type it, not even as a row of stars (******). It is going in, however!
· To run the graphical configuration utilities with sudo, simply launch the application via the menu.
· To run a program using sudo that normally is run as the user, such as gedit, press Alt+F2 and enter gksudo gedit.
· For users of Kubuntu, use kdesu in replacement for gksudo.
· To use sudo on the command line, preface the command with sudo, as below:
Example #1
sudo chown bob:bob /home/bob/*
Example #2
sudo /etc/init.d/networking restart
· NEVER use sudo to start graphical programs. You should always use gksudo or kdesu to run such programs, otherwise new login attempts may fail. If this happens and at login an error message reports: "Unable to read ICE authority file", log in using the failsafe terminal and execute the command below substituting your username for user.
rm /home/user/.{ICE,X}authority
· To start a root shell (i.e. a command window where you can run root commands), starting root's environment and login scripts, use:
sudo -i (equivalent to sudo su -)
· To start a root shell, but keep the current shell's environment, use:
sudo -s (equivalent to sudo su)
· To login as another user (on the command line, use something like gdmflexiserver for a graphical login)
sudo -i -u username
To add a new user to sudo, open the Users and Groups tool from System --> Administration menu. Then click on the user and then on properties. Choose the User Privileges tab. In the tab, find Executing system administration tasks and check that.
![]()
In the terminal this would be:
sudo adduser $user admin,
where you replace $user with the name of the user.
The benefits of leaving root disabled by default include the following:
· The installer has to ask fewer questions
· Users don't have to remember an extra password, which they are likely to forget
· It avoids the "I can do anything" interactive login by default -you will be prompted for a password before major changes can happen, which should make you think about the consequences of what you are doing.
· Sudo adds a log entry of the command(s) run (In /var/log/auth.log). If you mess up, you can always go back and see what commands were run. It is also nice for auditing.
· Every cracker trying to brute-force their way into your box will know it has an account named root and will try that first. What they don't know is what the usernames of your other users are.
· Allows easy transfer for admin rights, in a short term or long term period, by adding and removing users from groups, while not compromising the root account.
· sudo can be setup with a much more fine-grained security policy
· The authentication automatically expires after a short time (which can be set to as little as desired or 0); so if you walk away from the terminal after running commands as root using sudo, you will not be leaving a root terminal open indefinitely.
Although for desktops the benefits of using sudo are great, there are possible issues which need to be noted:
· Redirecting the output of commands run with sudo can catch new users out. For instance consider sudo ls > /root/somefile will not work since it is the shell that tries to write to that file. You can use ls | sudo tee -a /root/somefile to append, or ls | sudo tee /root/somefile to overwrite contents. You could also pass the whole command to a shell process run under sudo to have the file written to with root permissions, such as sudo bash -c "ls > /root/somefile".
· In a lot of office environments the ONLY local user on a system is root. All other users are imported using NSS techniques such as nss-ldap. To setup a workstation, or fix it, in the case of a network failure where nss-ldap is broken, root is required. This tends to leave the system unusable unless cracked. An extra local user, or an enabled root password is needed here.
· Isn't sudo less secure than su?
o The basic security model is the same, and therefore these two systems share their primary weaknesses. Any user who uses su or sudo must be considered to be a privileged user. If that user's account is compromised by an attacker, the attacker can also gain root privileges the next time the user does so. The user account is the weak link in this chain, and so must be protected with the same care as root.
On a more esoteric level, sudo provides some features which encourage different work habits, which can positively impact the security of the system. sudo is commonly used to execute only a single command, while su is generally used to open a shell and execute multiple commands. The sudo approach reduces the likelihood of a root shell being left open indefinitely, and encourages the user to minimize their use of root privileges.
· I won't be able to enter single-user mode!
o The sulogin program in Ubuntu is patched to handle the default case of a locked root password.
· I can get a root shell from the console without entering a password!
o You have to enter your password.
Console users have access to the boot loader, and can gain administrative privileges in various ways during the boot process. For example, by specifying an alternate init(8) program. Linux systems are not typically configured to be secure at the console, and additional steps (for example, setting a root password, a boot loader password and a BIOS password) are necessary in order to make them so. Note that console users usually have physical access to the machine and so can manipulate it in other ways as well.
![]()
This is not recommended!
Consider using the below command instead:
sudo -iThat will open up a root console temporarily. Enabling the root account in Ubuntu is neither supported nor necessary. Anything you need to do as administrator of an Ubuntu system can be done via sudo or gksudo.
If the root account is enabled and you wish to disable it, open a terminal and issue the following command:
sudo passwd -l root
This is a
trick from the
![]()
forums.
Create a launcher with the following command:
gksudo "gnome-open %u"
When you drag and drop any file on this launcher (it's useful to put it on the desktop or on a panel), it will be opened as root with its own associated application. This is helpful especially when you're editing config files owned by root, since they will be opened as read only by default with gedit, etc.
Go To Page [ 1 ] Go To Page [ 2 ] Go To Page [ 3 ] Go To Page [ 4 ]