1. There is a program called SWAT. SWAT is your friend.
[root@quickdraw log]# cat /etc/xinetd.d/swat
# default: off
# description: SWAT is the Samba Web Admin Tool. Use swat \
# to configure your Samba server. To use SWAT, \
# connect to port 901 with your favorite web browser.
disable = no
port = 901
socket_type = stream
wait = no
only_from = 127.0.0.1
user = root
server = /usr/sbin/swat
log_on_failure += USERID
If you have swat installed, an xinetd like the above allows you to
And no one off the box can see it.
Once you have samba configured, instead of leaving everything mounted all the time, you can run autofs/
I run autofs on one directory, /misc
A line in /etc/autofs.misc that reads as follows:
shareout -fstype=smb,username=guest,guest ://gateway/shareout
means that when I touch the file /misc/shareout -- the file suddenly exists and the mount is done, and I can see everyrhing in the directory.
But if I do a find / and I have not touched those files, then they are not mounted and are not accessed. I do this for floppies in different formats with different names in misc, or cdroms, or things on loopback devices even, cdrom images. If I had any NFS, I would do that as well.
By the way, when Windows did SMB at first, there was NFS, RFS on the Unix side, it was not clear that NFS was a winner. The security on NFS, when it first came out, was just completely lame. Essentially, it is all security through assertion - you were trusted because you occupied a piece of netspace and because you claimed that you were uid such and such. This was sort of OK when Unix boxen were glass house boxes that were accessed using serial terminals. But there was a transition into the "workstation" boxes that happened and this meant that the average user was suddenly their own administrator. We attempted to do a system with thousands of users, based on automounting people's home directories from their home boxes. It was a security nightmare. The only userid you could protect was root. NFS was really limited in early implementations because of the fact that every operation through NFS was forced to be completely stateless and atomic. The point was that you were supposed to be able to crash a server, and reboot it, and everyone who had a read on the server would just pause until the server came back. If you only had one server and your machines were diskless, this made sense. But it was impossible to extend this with fallback servers. And if you did not make the timeouts on mounts infinite, the failures were extended to the applications, they were not dealt with by allowing backup exact images.
But the reality is that, by far (a factor of 100 or more) when SMB came out, it was not competing with NFS, NFS was not even on the radar. It was competing with Netware.
I have seen this -- 400 workstations acting like a train station (you know, where the train stops) and the work stopped because one system had one process crash. So, since there was the master of a shared library on this box, the next time anyone typed a command on the box, the box froze.
With AFS, the processes would notice the dead server and switch to a backup - the backup would be readonly and the changed files would queue locally until the write server came back up. And it used kerberos and tokens for security rather than IP address and asserted uid numbers.
There have been NFS clients for MS-DOG since the 80286 days and before. Most sensible people would not let them on their networks. These days, Windows will give you a free NFS server and client for your XP or W2K or NT system. See http://download.microsoft.com/downlo...sfu35intro.doc
for details and if you want it you can download it at http://www.microsoft.com/windows/sfu/default.asp.
According to this, you can export cdfs or ntfs, but not a fat file system. I suspect this is because they are trying to maintain NFS ownership semantics.