Red Hat Topics - FC3 - trying to join a Windows Workgroup

Author

FC3 - trying to join a Windows Workgroup

Gordon Burgess-Parker

2005-05-14, 1:04 pm

I've installed Samba and it's running. I need a step-by-step guide on
what I need to configure to join a Windows Workgroup.
Also some information on what I should expect to see when I do join the
workgroup - the other machines are using Windows XP and NTFS formatted HDD.

Thanks

Ivan Marsh

2005-05-14, 1:04 pm

On Fri, 13 May 2005 18:10:20 +0100, Gordon Burgess-Parker wrote:

> I've installed Samba and it's running. I need a step-by-step guide on
> what I need to configure to join a Windows Workgroup.

WORKGROUP=<your workgroup name> in /etc/samba/smb.conf

service smb restart

> Also some information on what I should expect to see when I do join the
> workgroup - the other machines are using Windows XP and NTFS formatted
> HDD.

You won't see anything.

man smb.conf

--
Life is short, but wide. -KV

Gordon

2005-05-14, 1:04 pm

Ivan Marsh wrote:
> On Fri, 13 May 2005 18:10:20 +0100, Gordon Burgess-Parker wrote:
>
>
>
>
> WORKGROUP=<your workgroup name> in /etc/samba/smb.conf
>
> service smb restart
>
>
>
>
> You won't see anything.
>
> man smb.conf
>

So how do I share data on the Windows box with the Linux one?

Leythos

2005-05-15, 8:30 am

In article <3els5hF3ov6lU1@individual.net>, gordonbp1
@yahoo.co.uk.invalid says...
> Ivan Marsh wrote:
>
> So how do I share data on the Windows box with the Linux one?

I have many windows servers and have not been able to get this working
either - I can see the Windows shares from my FC3 box, but the FC3 user
only has read permission, not the permissions assigned on the Windows
server box (windows 2003 server).

--
--
spam999free@rrohio.com
remove 999 in order to email me

Miles Brennan

2005-05-15, 8:30 am

Gordon Burgess-Parker wrote:
> I've installed Samba and it's running. I need a step-by-step guide on
> what I need to configure to join a Windows Workgroup.
> Also some information on what I should expect to see when I do join the
> workgroup - the other machines are using Windows XP and NTFS formatted HDD.
>
> Thanks

Here's a simple guide (see chapter 18): http://www.brennan.id.au/

It was written more for configuring the Linux daemon so windows clients
can connect, however there is a small section at the bottom that details
how to use the smbclient to connect to Windows boxes or other Samba servers.

ie....
findsmb
smbclient winbox1
smbmount //winbox1/C$ /media/winbox1/cdrive -o username=administrator
.....

Miles.

Gordon

2005-05-15, 8:30 am

Miles Brennan wrote:
> Gordon Burgess-Parker wrote:
>
>
>
> Here's a simple guide (see chapter 18): http://www.brennan.id.au/
>
> It was written more for configuring the Linux daemon so windows clients
> can connect, however there is a small section at the bottom that details
> how to use the smbclient to connect to Windows boxes or other Samba
> servers.
>
> ie....
> findsmb
> smbclient winbox1
> smbmount //winbox1/C$ /media/winbox1/cdrive -o username=administrator
> ....
>
>
> Miles.

Many thanks for the info - looks like a good site for future reference!

--
Registered Linux User no 240308
gordonATgbpcomputingDOTcoDOTuk
to email me remove the obvious!

Jeff Cummings

2005-05-15, 5:45 pm

I have never been able to get this working . I have defined 2 shares and I
don't even see them on windows. I can print from Linux to windows, but I
cannot see the file shares on windows. Is there anything special I have to
do on widows. I am running win 2000 server, winME and win98. Any
suggestions?

--

Jeff Cummings
"Ivan Marsh" <annoyed@you.now> wrote in message
news:pan.2005.05.13.21.33.54.942273@you.now...
> On Fri, 13 May 2005 18:10:20 +0100, Gordon Burgess-Parker wrote:
>
>
> WORKGROUP=<your workgroup name> in /etc/samba/smb.conf
>
> service smb restart
>
>
> You won't see anything.
>
> man smb.conf
>
> --
> Life is short, but wide. -KV
>

James Bridge

2005-05-16, 5:46 pm

On Sat, 2005-05-14 at 09:45 +0100, Gordon wrote:
> Ivan Marsh wrote:
>
> So how do I share data on the Windows box with the Linux one?

Configure the Linux firewall! You can do it from the GUI - click on
Applications - System Settings - Security Level (root password required)
and then set your local network (eth0 ?) as a "trusted device". I don't
know what other security implications this has but suddenly all the
Windows machines become visible, in Computer/Network.

Apart from this, the only other thing you need to do is put the Windows
workgroup name in the smb.conf file, and you can do this from
Applications - System Tools - Configuration Editor and then selecting
System - smb in the sidepanel.

Ivan Marsh

2005-05-16, 5:46 pm

On Sat, 14 May 2005 21:14:37 +0000, Leythos wrote:

> In article <3els5hF3ov6lU1@individual.net>, gordonbp1
> @yahoo.co.uk.invalid says...
>
> I have many windows servers and have not been able to get this working
> either - I can see the Windows shares from my FC3 box, but the FC3 user
> only has read permission, not the permissions assigned on the Windows
> server box (windows 2003 server).

Okay... well, contrary to unpopular belief and a lot of traffic on the
newsgroups SAMBA and XP work and play just fine with each other even if
SP2 is installed.

The quick and dirty SAMBA setup guide:

First things first, make it part of a workgroup:

WORKGROUP=MYWORKGROUP - should be caps and the exact name of the workgroup
or domain your windows boxes are in. This should NOT be over eight
characters or have any spaces or underscores in it. (though, otherwise, it
may work with linux, and probably will; these rules were established for
NT 4.0, not Linux)

Check hosts allow:

hosts allow=<host or network> - if commented out all hosts are allowed.

Check browsemaster/domainmaster sections.

Most of these options can be left default without affecting function. I
like to turn most of it off because I'm connected to a MS domain that
takes care of all this stuff just fine.

Create a share:

[test]
comment = This is a test share
browseable = yes # will show up in network neighborhood
path = /var/test
valid users = @users # allow access for the "users" group
public = no # must have explicit rights to share (no guest)
writeable = yes
printable = no # ALL non-printers should have this entry
create mask = 0660
directory mask = 0770

Restart the service:

service smb restart.

Create your samba/windows account mapping with smbpasswd. This tells samba
what windows user to map to what linux user.

At this point you should be able to see your linux box in the network
neighborhood with a share "test".

If you can't:

Run testparm - this will evaluate your /etc/samba/smb.conf and tell you if
you have any errors in it.

Is the firewall on your Linux box blocking the traffic?

Is the firewall on your XP box blocking the traffic? ...REMEMBER: if
you've loaded service pack 2 for XP your machine is blocking ALL ACK and
broadcast traffic to your machine by default. I don't use the SP2/XP
firewall because it's, well, a complete POS. I use the free version of the
Sygate firewall on my Windows boxes because it allows for a more flexible,
easier setup.

If it still doesn't work:

Do you have a domain name resolution issue with either machine? If a
machine can't identify itself to itself it can't be expected to
identify itself to any other machine. Check your Windows boxes and make
sure their host files, DNS servers, routes, etc are correct. Check the
same on the linux box (/etc/hosts, /etc/resolve.conf).

BTW: the default for the /etc/hosts file on some Linux distros are
incorrect, or at least, not correct enough for some software to run
correctly. I think they do it this way by default so that everything
will work at install. This is in the form:

127.0.0.1 localhost.localdomain localhost <myrealhostname>.<myrealdomain>
<myrealhostname>

This, in my opinion, is a malformed hosts file and it doesn't surprise me
that some things don't work.

the hosts file should be:

127.0.0.1 localhost.localdomain localhost
<myrealip> <myrealhostname>.<myrealdomain> <myrealhostname?

The first form makes all traffic hit the loopback before it gets to the
correct interface. The second form properly segregates loopback and
network traffic and should even improve performance in general.

Assuming all this has been done you shouldn't be able to tell the
difference between your SAMBA server and any Windows box on your network
(except maybe the SAMBA server doesn't fail quite as much... sorry, had to.)

Beyond this you're out of the normal *gotcha* stuff for SAMBA and some
detail troubleshooting will have to be done.

Once you have this working I'll be happy to work out the: "well, now I can
see the share but it always says access denied" question.

--
Life is short, but wide. -KV

Leythos

2005-05-17, 2:46 am

In article <pan.2005.05.16.18.07.54.54199@you.now>, annoyed@you.now
says...
> On Sat, 14 May 2005 21:14:37 +0000, Leythos wrote:
>
>
> Okay... well, contrary to unpopular belief and a lot of traffic on the
> newsgroups SAMBA and XP work and play just fine with each other even if
> SP2 is installed.
>
> The quick and dirty SAMBA setup guide:
>
> First things first, make it part of a workgroup:
>
> WORKGROUP=MYWORKGROUP - should be caps and the exact name of the workgroup
> or domain your windows boxes are in. This should NOT be over eight
> characters or have any spaces or underscores in it. (though, otherwise, it
> may work with linux, and probably will; these rules were established for
> NT 4.0, not Linux)
>
> Check hosts allow:
>
> hosts allow=<host or network> - if commented out all hosts are allowed.
>
> Check browsemaster/domainmaster sections.
>
> Most of these options can be left default without affecting function. I
> like to turn most of it off because I'm connected to a MS domain that
> takes care of all this stuff just fine.
>
> Create a share:
>
> [test]
> comment = This is a test share
> browseable = yes # will show up in network neighborhood
> path = /var/test
> valid users = @users # allow access for the "users" group
> public = no # must have explicit rights to share (no guest)
> writeable = yes
> printable = no # ALL non-printers should have this entry
> create mask = 0660
> directory mask = 0770
>
> Restart the service:
>
> service smb restart.
>
> Create your samba/windows account mapping with smbpasswd. This tells samba
> what windows user to map to what linux user.
>
> At this point you should be able to see your linux box in the network
> neighborhood with a share "test".
>
> If you can't:
>
> Run testparm - this will evaluate your /etc/samba/smb.conf and tell you if
> you have any errors in it.
>
> Is the firewall on your Linux box blocking the traffic?
>
> Is the firewall on your XP box blocking the traffic? ...REMEMBER: if
> you've loaded service pack 2 for XP your machine is blocking ALL ACK and
> broadcast traffic to your machine by default. I don't use the SP2/XP
> firewall because it's, well, a complete POS. I use the free version of the
> Sygate firewall on my Windows boxes because it allows for a more flexible,
> easier setup.
>
> If it still doesn't work:
>
> Do you have a domain name resolution issue with either machine? If a
> machine can't identify itself to itself it can't be expected to
> identify itself to any other machine. Check your Windows boxes and make
> sure their host files, DNS servers, routes, etc are correct. Check the
> same on the linux box (/etc/hosts, /etc/resolve.conf).
>
> BTW: the default for the /etc/hosts file on some Linux distros are
> incorrect, or at least, not correct enough for some software to run
> correctly. I think they do it this way by default so that everything
> will work at install. This is in the form:
>
> 127.0.0.1 localhost.localdomain localhost <myrealhostname>.<myrealdomain>
> <myrealhostname>
>
> This, in my opinion, is a malformed hosts file and it doesn't surprise me
> that some things don't work.
>
> the hosts file should be:
>
> 127.0.0.1 localhost.localdomain localhost
> <myrealip> <myrealhostname>.<myrealdomain> <myrealhostname?
>
> The first form makes all traffic hit the loopback before it gets to the
> correct interface. The second form properly segregates loopback and
> network traffic and should even improve performance in general.
>
> Assuming all this has been done you shouldn't be able to tell the
> difference between your SAMBA server and any Windows box on your network
> (except maybe the SAMBA server doesn't fail quite as much... sorry, had to.)
>
> Beyond this you're out of the normal *gotcha* stuff for SAMBA and some
> detail troubleshooting will have to be done.
>
> Once you have this working I'll be happy to work out the: "well, now I can
> see the share but it always says access denied" question.

Thanks for all the info. I have Windows 2003 servers that I'm trying to
access using my FC3 box, so it's not really a work group, but I
understand the idea.

I can use the netbios name instead of the DNS name, the FC3 box can ping
the server by name without any problem, I can get a full list of shares
and folders and even files, but when I double click on a document it
gives me a permission error.

--
--
spam999free@rrohio.com
remove 999 in order to email me

Ivan Marsh

2005-05-17, 5:46 pm

On Tue, 17 May 2005 03:10:49 +0000, Leythos wrote:

> In article <pan.2005.05.16.18.07.54.54199@you.now>, annoyed@you.now
> says...
>
> Thanks for all the info. I have Windows 2003 servers that I'm trying to
> access using my FC3 box, so it's not really a work group, but I
> understand the idea.

Workgroup/Domain... it's the same thing to anything that can't register
itself in active directory.

> I can use the netbios name instead of the DNS name, the FC3 box can ping
> the server by name without any problem, I can get a full list of shares
> and folders and even files, but when I double click on a document it
> gives me a permission error.

Okay... at this point you need to start thinking about SAMBA the same way
you think about making shares under Windows.

I'm assuming you've created the account mapping necessary with smbpasswd.
If that mapping isn't there nothing is going to work right.

Share permissions != filesystem permissions.

If, under Windows, you create a share "test" that shares c:\tempdir and
give the TESTSHARE group rights to the share, you still can't do anything
with that share, even if you're a member of the TESTSHARE group, unless
the TESTSHARE group has filesystem rights to c:\tempdir.

The same is true of SAMBA.

Creating a share under SAMBA:

[myfiles]
comment = test share
browseable = yes
path = /var/myfiles
valid users = @users
public = no
writeable = yes
printable = no
create mask = 0660
directory mask = 0770

You can control read/write permissions to the share with the share...
But you cannot give someone rights to the filesystem with the share.

In this example if the group "users" doesn't have filesystem access to the
/var/myfiles directory members of the "users" group still have no rights
to the share.

So, if /var/myfiles has permissions/ownership "drwxrwx--- root:root" you
won't be able to get to the share even if you're a member of "users".

I set up my SAMBA shares so they have the permissions/ownership they need
and so they will maintain that p/o in all the subdirectories when new
files/dirs are created.

The /var/myfiles directory would then need to be "drwxrws--- root:users".

If you're not familiar with the "s" in the directory permissions that's
the SGID flag. Set it with chmod g+s <directory>. That flag means all
directories created under that directory will keep the group ownership of
the parent directory.

With those permissions set and the create/directory mask entries in the
shares all new files and dirs written to the share will maintain the
correct p/o and file rights.

Dropping a file into that share from Windows will create the file with the
p/o "rw-rw---- <your user name>:users" and a new directory will be
created as "drwxrws--- <your user name>:users" which is what you want.

If the rights aren't set up to maintain proper p/o and file rights you
will end up in a position where you can write a file to a share but then
you and/or others in your group have no rights to the file because the
file would end up marked with permissions from your default UMASK and will
belong to <your user name>:<your personal group>. Which means you will
still be able to get to the file but no one else from the "users" group
will be able to.

This may seem confusing at first but it's exactly the same way Windows
works... it just seems like it isn't.

--
Life is short, but wide. -KV

Leythos

2005-05-18, 5:51 pm

Thanks for the details, I will try this later this week. You've given me
a lot to think about and a better understanding.

Thanks!

In article <pan.2005.05.17.16.11.16.722515@you.now>, annoyed@you.now
says...
> On Tue, 17 May 2005 03:10:49 +0000, Leythos wrote:
>
>
> Workgroup/Domain... it's the same thing to anything that can't register
> itself in active directory.
>
>
> Okay... at this point you need to start thinking about SAMBA the same way
> you think about making shares under Windows.
>
> I'm assuming you've created the account mapping necessary with smbpasswd.
> If that mapping isn't there nothing is going to work right.
>
> Share permissions != filesystem permissions.
>
> If, under Windows, you create a share "test" that shares c:\tempdir and
> give the TESTSHARE group rights to the share, you still can't do anything
> with that share, even if you're a member of the TESTSHARE group, unless
> the TESTSHARE group has filesystem rights to c:\tempdir.
>
> The same is true of SAMBA.
>
> Creating a share under SAMBA:
>
> [myfiles]
> comment = test share
> browseable = yes
> path = /var/myfiles
> valid users = @users
> public = no
> writeable = yes
> printable = no
> create mask = 0660
> directory mask = 0770
>
> You can control read/write permissions to the share with the share...
> But you cannot give someone rights to the filesystem with the share.
>
> In this example if the group "users" doesn't have filesystem access to the
> /var/myfiles directory members of the "users" group still have no rights
> to the share.
>
> So, if /var/myfiles has permissions/ownership "drwxrwx--- root:root" you
> won't be able to get to the share even if you're a member of "users".
>
> I set up my SAMBA shares so they have the permissions/ownership they need
> and so they will maintain that p/o in all the subdirectories when new
> files/dirs are created.
>
> The /var/myfiles directory would then need to be "drwxrws--- root:users".
>
> If you're not familiar with the "s" in the directory permissions that's
> the SGID flag. Set it with chmod g+s <directory>. That flag means all
> directories created under that directory will keep the group ownership of
> the parent directory.
>
> With those permissions set and the create/directory mask entries in the
> shares all new files and dirs written to the share will maintain the
> correct p/o and file rights.
>
> Dropping a file into that share from Windows will create the file with the
> p/o "rw-rw---- <your user name>:users" and a new directory will be
> created as "drwxrws--- <your user name>:users" which is what you want.
>
> If the rights aren't set up to maintain proper p/o and file rights you
> will end up in a position where you can write a file to a share but then
> you and/or others in your group have no rights to the file because the
> file would end up marked with permissions from your default UMASK and will
> belong to <your user name>:<your personal group>. Which means you will
> still be able to get to the file but no one else from the "users" group
> will be able to.
>
> This may seem confusing at first but it's exactly the same way Windows
> works... it just seems like it isn't.
>
>

--
--
spam999free@rrohio.com
remove 999 in order to email me