[Nov 23, 2009 14:09] Web access to Microsoft Live@edu accounts now works.
Accessing Home Directory on a RedHat Linux Computer
The Home Directory Service (HDS) resides on two Network Appliance file servers named home1.Virginia.EDU and home2.Virginia.EDU.
To connect to the Home Directory Service (HDS) from Linux, you must have the samba-common and samba-client packages installed, and your kernel must have the smbfs module, which is a standard Linux kernel module. (See note below for RedHat 7.1 and higher versions.)
To access your HDS directory, make an empty local directory where you want to mount your HDS directory. For example: mkdir /mnt/hds
To mount your HDS directory, run the following command as root:
smbmount //home1.Virginia.EDU/hdslogin /mnt/hds \
-o username=ESERVICES\\hdslogin,uid=linuxlogin,ip=home1.Virginia.EDU
Some users may be required to use an alternate syntax:
smbmount //home1.Virginia.EDU/hdslogin /mnt/hds \
-o username=hdslogin/eservices,uid=linuxlogin,ip=home1.Virginia.EDU
where hdslogin is your HDS loginid, and linuxlogin is your Linux loginid (in case they are different). You will be prompted for your HDS password. Your HDS when connecting with smbmount is your Eservices password.
With Fedora 6, the smbmount command has disappeared, but
mount -t cifs //home1.Virginia.EDU/hdslogin /mnt/hds \
-o username=eservices/hdslogin,uid=linuxlogin
does the same thing; hdslogin is your HDS login, linuxlogin is your Linux loginid (in case they are different).
The mount command has to run as root, and without the uid option, the
workstation will display everything in the mounted share as owned
by root.
The value of the uid parameter determines what owner is displayed
in the mounted share.
Regardless of the uid used, ownership of the files and directories under the share you access are managed by the file server, not by your Linux client system. In a share where multiple users may own files, on the Linux system accessing them everything will be displayed as being owned by the uid used in the mount, but the server did not change the owner. A file on the server which is not owned by your hdslogin ID, and has permissions set that exclude your hdslogin ID from having access, may appear in the mounted directory on your Linux client system, and appear to be accessible by your linuxlogin ID, but you will not be permitted to access it.
If your files are on the HDS server home2, then use home2 instead of home1, and if mounting a department share, use //home2.Virginia.EDU/sharename above.
If smbmount succeeds, then your HDS directory is mounted on the local directory /mnt/hds. Your HDS files appear in this directory and any changes you make under this directory actually happen on the HDS. For the most part you can use normal Linux commands to manipulate your HDS files as if they were local files. To unmount your HDS directory, run this command as root: smbumount /mnt/hds
Smbumount fails with a device busy error if any HDS file is still open, or if any HDS directory is the current working directory of any Linux process, so be sure to cd out of /mnt/hds before trying to unmount it.
For more details, see the man pages for smbmount and smbumount.
You may want to access a HDS share other than your own home directory. For example, //home1.Virginia.EDU/home is the top level directory for all accounts on home1. If you mount this, then you need to "drill down" to find what you want. For example, if your loginid is abc9d then your HDS directory is located at /mnt/hds/a/ab/abc9d.
You can also access your HDS directory with smbclient, but it is just as easy, and more secure, to access blue.unix with scp or sftp instead.
smbmount and UNIX File Permissions
The HDS file servers support both the UNIX NFS and Windows CIFS (SMB) file sharing protocols. Linux can access files using either of these protocols. But due to file security issues, we do not allow personal Linux workstations to access the HDS with NFS, so you must use the Linux smbmount command to access the HDS with CIFS.
Most ITC administered UNIX systems, such as blue.unix, the IBM SP2, and the ITC UNIX Lab, use NFS to access the HDS file servers, so the HDS looks just like a local UNIX file system. File protection works just like on a local UNIX file system. When using smbmount (CIFS), however, the HDS looks like a Windows (DOS) fat32 file system, which has a different file protection mechanism than UNIX. You can still read and write HDS files with CIFS just fine, provided you have the necessary access rights. The HDS file servers are configured to use UNIX file protection even when files are accessed with CIFS. When you login to the HDS with smbmount, the resulting CIFS session has the same file access rights that you have when you login to blue.unix.
When you inspect HDS file permissions from Linux using the ls -l command, you do not get accurate information because CIFS cannot provide this information. Linux just fills it in. You are listed as the owner of every file, and the group is always root. The file permissions are fictitious. To inspect and manipulate your HDS file permissions, you should login to your blue.unix account.
You can use the chmod command on Linux to modify the permissions of HDS files, but it doesn't work like you think. In a fat32 file system, each file has a readonly bit and the HDS file servers implement this bit, but it is separate from the UNIX permissions. If you enable the readonly bit from CIFS, it has the side effect of disabling all UNIX write permissions. If you disable the readonly bit from CIFS, it restores any underlying UNIX write permissions. So the Linux chmod command can only manipulate the readonly bit on HDS files, which may or may not do what you want. You need to run chmod on blue.unix.
When you create a new HDS file or directory from Linux, the HDS file server sets the owner and group of the new file just like UNIX does. The file owner is the HDS user logged in with smbmount. The file group is the primary group of the HDS user, which is the same as on blue.unix. However, if the parent directory of the new file has set group enabled, then the new file inherits its group from the parent directory. Since CIFS provides no UNIX file permission information, the new HDS file inherits its permissions from the parent directory. This behavior is what you want in most circumstances.
If you modify or overwrite an existing HDS file from Linux, no changes happen to the file owner, group, or permissions. For example, if you copy a local Linux file to an existing HDS file with the cp command, the owner, group, and permissions of the HDS file do not change.
Multi-User Linux Systems
It is probably best to use smbmount on a personal Linux workstation rather than on a multi-user Linux system. This is because all Linux users have equal access rights to HDS files that have been mounted with smbmount. The HDS server enforces file protection, not Linux. And the HDS server uses the access rights of the HDS user logged in with smbmount. So in effect, all users on a multi-user Linux system have the access rights of the HDS user.
You can work around this problem by mounting your HDS directory on a directory that is beneath a protected directory. That way the protected directory blocks other Linux users from getting to your mounted HDS directory.
By default only superuser (root) can run smbmount and smbumount. You can enable set user on the /usr/bin/smbmnt and /usr/bin/smbumount executable files so that ordinary users can run smbmount and smbumount. Beware that enabling set user can have unforseen security consequences, but problems are rare. Ordinary users can only mount over directories where they have write access.
Caveats
RedHat 7.1 and earlier
The Linux kernel distributed with RedHat Linux 7.1 and earlier has a problem in the smbfs module. You cannot list the contents of any HDS directory with more than 80 items. When you run ls on a large HDS directory, nothing prints. You can still access a file in a large directory if you know its name. Wildcards do not work. This is fixed in a newer kernel than the one shipped with RedHat 7.1.
As mentioned above, ls -l does not accurately show file owner, group, or permissions due to CIFS limitations. Furthermore, you can only manipulate the fat32 readonly bit with chmod. To inspect and manipulate UNIX file permissions, you need to login to blue.unix.
RedHat 7.2 and later
The version of samba distributed with RedHat Linux 7.2 and later will not work with the current version of the NetApp that accesses home directories on blue.unix. The fix is to uninstall both samba-common and samba-client. If using RedHat Linux 7.2, you must download version 2.0.7-36 of both samba-common and samba-client and install them. If using version 7.3, you must download version 2.2.7-1.7.3 of both samba-common and samba-client and install them. You may get this software from the ITC Linux site.
Questions or comments should be sent to helpdesk@virginia.edu.