Ted Miller wrote: > >> Is samba running there? If so, you are mostly done. > > Yes, at the moment I have Samba running, but apparently not properly > configured. I am also in the process of moving this machine from Centos > 4 to Centos 5, and am trying to do it better this time. At the moment > office2 is dual boot, still defaulting to C4. I don't think there should be a big difference samba-wise. >> If you aren't already using samba, you need to 'smbpasswd >> -a username' for each user and input the password (or go around and >> let them type it themselves). > > Done at this point. > >> After this, a windows user mapping a samba-shared directory from your >> office2 machine will have the same access as the same user logged in >> locally. There are the same issues with directories that users share >> with group permissions, but samba offers some extra options to force >> owner/group/permissions on newly created files that will help. > > That is something I need to fix, because I do have some issues with > group accessed files, where certain operations require me to log in as > root and run a script that cleans up the file ownership, otherwise some > users can no longer access the files. Any pointers on where to find > documentation on this? Newly created files default to having the group ownership of the primary group of the user creating it, and the RH scheme is to give every user his own group. You can do something like this in the samba share configuration: valid users = @groupname force group = groupname force create mode = 0775 force directory mode = 0775 This will make new files have the right group and r/w (and executable, which you might not want). If files are also created on the Linux side you need to 'chmod g+s' on the directory to make new files take the group of the directory. You can find samba docs here: http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/ > I have been using 'share' mode, but a little reading makes it sound like > I should switch to 'user' mode to make my life easier. I have been > adding various user permission lines to each share. Will they keep > working if I just comment out those lines? Share vs. user doesn't make a difference in how things work after the connection is established - it controls when authentication happens. Share mode just lets you browse the share list before authenticating and you can connect to different shares with different credentials. >> You might look at webmin, since it has an option to maintain unix and >> samba passwords at the same time and it can also keep multiple >> machines in sync. > > Does anyone maintain webmin for Centos? I have most of the common repos > hooked to yum, but webmin draws a blank. This is one of the reasons I usually install k12ltsp instead of the stock centos distribution (you don't lose anything, it just adds some extras and makes the updates yummable). You probably can grab the RPM directly from the webmin site. >> The other complication is that if you also want to share files via >> NFS, the permissioning mechanism is entirely different. NFS just >> looks at the uid/gid/modes like a local file, so you need to make the >> password files consistent across all the Linux boxes. > > Does NFS work with windows? I have wasted considerable time on Google > trying to answer that question, and the only answer I find is that there > are commercial products that (for a per-seat fee) will connect windows > to NFS. On windows you would use 'services for unix'. But I'd stick to samba. > I read that NFS v.4 was supposed to "play better" with windows, > but I could not find any official comment, or windows drivers, or even > any recommendations of client only drivers. Don't know about that. >> There is also the issue that users who have root access to their own >> workstation can pretend to be any user over NFS. > > Not an issue in this situation, users do not have root access. Do they have the same uid/gid, and group lists on their workstations as on the file server? >> For a single-user Linux workstation scenario, it might make more sense >> to only provide samba shares and use cifs mounts instead of NFS. NFS >> makes more sense between multiuser unix/linux boxes where only the >> administrator(s) have root access. > > That is what I did under C4, but with considerable frustration, but > maybe a simplified version of what I had (minus per-share permission > listing in smb.conf) would get me most of what I want. If it is one user per workstation, treating it just like the windows connections with samba should work. >> I don't think you need to code anything since there are already >> several options with varying degrees of complexity. Centralizing >> authentication will help if you have many users and password changes. >> But that can be as simple as turning on domain controller emulation on >> samba on your office2 server and configuring everything else (windows >> and Linux) to use it. > > Any pointers to where I could learn the implications/pluses/minuses of > that? It might be useful with my multiple machines (real and virtual) > per user. Samba authentication for linux just checks that a login/password match. You still have to create the users and if you use NFS, make sure the uid/gid's are all the same. For windows it works like a domain controller and once you've logged in as a windows user, you automatically authenticate to the samba shares as the same user and the server can force login scripts to run on the client. >> If these remote users are doing anything but video editing, another >> useful option might be to use remote X logins or freenx/NX for a >> remote Linux desktop directly from your office2 machine instead of >> accessing its files on their workstation. How well it works depends >> on what they are doing and the relative CPU and video use compared to >> file access. > > Video editing is getting done on a windows-native-boot laptop. Video > editing seems to be something that open source doesn't do very well. I use a mac for the little I do, but I thought that http://cvs.cinelerra.org/docs.php and http://lives.sourceforge.net were supposed to be getting better. -- Les Mikesell lesmikesell at gmail.com