Tech Line

Share Nice!

Share home folders between Windows and Linux desktops.

Chris: I'd like to thank Bill Boswell for writing such a great how-to for winbind authentication. [See Bill's Windows Insider column on Linux single sign-On on the Redmond Magazine site at http://redmondmag.com/columns/article.asp?EditorialsID=858 and "Hat Trick" on the MCPmag.com site at http://mcpmag.com/columns/article.asp?EditorialsID=976.—Editor] I'm very close to implementing this solution in the Linux lab that I manage here at Cornell, but the drawback so far is the lack of automatically mounting Samba drives. Can you recommend a solution for mounting Samba shares at user login time?

Here at school, we have an H: drive and W: drive (home and web, respectively) that would facilitate students' learning immenselycurrently there's no easy way for students to get their files from the Linux side to the Windows sideif they were automatically mounted and appeared on the Linux desktop upon login. We are dual-booting Windows XP/Fedora Core 3 on all of our lab workstations. From everything I've seen, mounting a Samba share requires something to be run as root, which I don't like. Is there another solution that you've seen?
— Ian

Tech Help—Just An
E-Mail Away

Got a Windows, Exchange or virtualization question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to the MCPmag.com editors at mailto:editor@mcpmag.com; the best questions get answered in this column and garner the questioner with a nifty MCPmag.com baseball-style cap.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message, but submit the requested information for verification purposes.)

Ian: One of my favorite aspects of working with Linux is that it completely falls in line with the definition of insanity. With Linux, many of us have found that you truly can perform the same task over and over on different Linux boxes and expect a different result. Usually you'll get it! Since the Linux community has been touting its many advantages for several years now, it looks like they forgot one—hope for the mentally insane.

Of course, most of the "problems" we run into with Linux is due to the fact that it is such a customizable and flexible OS (I feel the need to add this note before some of you Linux diehards start to crucify me). Flexibility is great, especially when you look at how companies like VMware and Check Point have bundled some of their applications with a Linux OS that has been optimized for their particular product. On the other hand, it makes documenting solutions very challenging. I know...you get the point! So I'll move on and show you how I solved this problem.

As you've mentioned, mapping drives from the Windows XP workstations is simple, but accessing the same resources from the Linux workstations via smbmount is another story. There are a couple of ways to solve this problem from the Linux workstations. Since your shares reside on a Samba server, one relatively simple solution is to configure the Samba server to also act as an NFS server. This way, Windows users can access the shares using CIFS, and the Linux workstations can have access to the same data using NFS.

In my test lab, I have a small LAN with a Windows 2003 domain controller, a Red Hat Enterprise Linux AS 4.0 server configured as my Samba server, along with a Windows XP workstation and a Red Hat Enterprise Linux 4.0 workstation. Winbind authentication is setup on both Linux systems and the methods that I used to configure winbind are consistent with Bill Boswell's original articles on the subject.

At this point, I'm making the assumption that you can successfully logon to both the Windows and Linux workstations as a domain user. To allow NFS mounts of the shared folders on the Linux server, I first configured NFS to export my Samba server's home folder share and its public share. Here's the contents of my /etc/exports file:

/home/REDMONDMAG 192.168.0.0/24(rw,sync)
/usr/public 192.168.0.0/24(rw,sync)

My clients were all on the 192.168.0.x LAN, so I configured the NFS exports to accept connections from any host on the 192.168.0.0/24 network. Both exported folders were set to allow read and write access. I realize that this setup is simple (security administrators, don't pop a vein here!), but for your purpose of sharing data in a single classroom setting it should work fine. As you'll see, after configuring the client-side settings, users will only see their own home folder. While all users will be able to see the public folder, ultimately the permissions of each "public" subfolder and file would ultimately determine user access.

Now on the client side, I mounted the remote home folders using autofs. To enable the remote home folder mount, I modified the /etc/auto.master file on each client to include the line:

/home /etc/auto.home

This entry will auto-mount the location specified in the /etc/auto.home file into the /home folder. Next, I created the /etc/auto.home file and added the following line:

* -fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid rhas4-fs1.redmondmag.com:/home/REDMONDMAG

This will redirect the user home folder location to the rhas4-fs1.redmondmag.com:/home/REDMONDMAG NFS mount point (rhas4-fs1 is the name of my NFS/Samba server).

For the public share, I edited the /etc/fstab file on the Linux workstation so that it would auto mount the remote "public" folder on boot-up. Here's the line that I added to /etc/fstab:

rhas4-fs1.redmondmag.com:/usr/public /public nfs rw,soft,intr,rsize=8192,wsize=8192 0 0

This will now auto-mount the /usr/public share on the NFS/Samba server. If you're curious about the NFS mount options that I used, or want more information on auto-mounting file systems in Red Hat Linux, take a look at http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/ref-guide/s1-nfs-client-config.html.

Note that with the default Red Hat firewall configuration, NFS traffic is blocked. For NFS mounts to succeed, IPTables need to be set up to allow the default NFS port (2049).

While slightly more complex, you may prefer using the package smbpwman. Smbpwman can collect user passwords at logon and pass them to a smbmount statement. See http://uranus.it.swin.edu.au/~jn/linux/smbfs/ for additional details on this method.

Just like there's more than one way to skin a cat, there are plenty of ways to pluck a penguin. In production, you'll likely be much more restrictive in the hosts that you allow read and write access to the NFS mounts. Hopefully, this solution will get you on the path to sharing data between both Windows and Linux workstations.

About the Author

Chris Wolf is a Microsoft MVP for Windows --Virtual Machine and is a MCSE, MCT, and CCNA. He's a Senior Analyst for Burton Group who specializes in the areas of virtualization solutions, high availability, storage and enterprise management. Chris is the author of Virtualization: From the Desktop to the Enterprise (Apress), Troubleshooting Microsoft Technologies (Addison Wesley), and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).learningstore-20/">Troubleshooting Microsoft Technologies (Addison Wesley) and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).

comments powered by Disqus

SharePoint Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.