Samba won't dance [Solved - sort of]
Claude Jones
cjones at levitjames.com
Mon Apr 21 18:20:43 UTC 2008
On Saturday April 19 2008 11:51:26 am Claude Jones wrote:
> On Saturday April 19 2008 11:23:06 am Craig White wrote:
> > On Sat, 2008-04-19 at 09:44 -0400, Claude Jones wrote:
> > .................snip....................
> >
> > > 137, 138, 139, and 445... Any other suggestions on what I
> > > should try?
> >
> > ----
> > indeed...see above
> >
> > it's entirely possible that there is a change from LAN
> > segment to wireless segment in something as inane as the
> > MTU.
>
> I'll take those suggestions and try them when I get home.
>
To put a possibly new ending on this thread, I mostly have
everything working now. I switched form firestarter to the
Fedora utility, system-config-firewall, the version that's in
rawhide. There was no ambiguity about rules in this GUI. I post
the following for information:
# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere
reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp
any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp
dpt:mdns
ACCEPT udp -- anywhere anywhere udp
dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp
dpt:ipp
ACCEPT all -- anywhere anywhere
state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere
state NEW tcp dpt:domain
ACCEPT udp -- anywhere anywhere
state NEW udp dpt:domain
ACCEPT tcp -- anywhere anywhere
state NEW tcp dpt:smtp
ACCEPT udp -- anywhere anywhere
state NEW udp dpt:netbios-ns
ACCEPT udp -- anywhere anywhere
state NEW udp dpt:netbios-dgm
ACCEPT tcp -- anywhere anywhere
state NEW tcp dpt:netbios-ssn
ACCEPT tcp -- anywhere anywhere
state NEW tcp dpt:microsoft-ds
ACCEPT tcp -- anywhere anywhere
state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere
state NEW tcp dpt:nfs
REJECT all -- anywhere anywhere
reject-with icmp-host-prohibited
******************************************************
The above rule-set is much simpler and clearer than the one
generated by Firestarter. This did not end up fixing the issues
I was having, unfortunately. The final piece in the puzzle was
yielded up by some curious log messages I was getting, and by
some errors I was getting running Konqueror related to DCOP
(from their home page: "DCOP is a simple IPC/RPC mechanism built
to operate over sockets...Each application using DCOP is a
client. They communicate to each other through a DCOP server,
which functions like a traffic director, dispatching
messages/calls to the proper destinations.") The DCOP component
of KDE was somehow getting it's configuration files mangled in
some way, which was having the effect of occasionally locking up
my file-browser window. Running the following
command, "rm /home/cj/.DCOPserver_*__0" and rebooting seemed to
fix it temporarily, but, then I learned there was an issue
related to my problem, that had been fixed in an upcoming
version of some KDE related files, that would become available
soon. I reverted my kdebase to an earlier version after another
lockup occurred, even though I was able to cure it again by
running the above command. Along in there, I also deleted the
two Samba socket options from my samba.conf that Craig suggested
I take out in a previous post in this thread. Those changes
seemed to take care of things. I'm now successfully able to see
all shares on all machines, and mount them, from my Fedora box.
All Windows boxes can see the shared directory and printer on my
Fedora box, and can print to the shared printer. That's lasted
about 18 hours so far... I'm using the utility smbk4 on Fedora
to see my Windows shares and mount them - once mounted, they all
appear in a folder, smbk4, in my home directory, and clicking on
those shares yields up all the shared directories on my Windows
boxes. One other thing I changed along in there was to name the
Fedora box as the domain master and preferred master, and it's
now reliably getting elected as the master browser - this is the
one machine that's always on in my household, so it seemed to
make sense.
Hope this helps someone - if someone spots any errors in what
I've done, please let me know.
--
Claude Jones
Brunswick, MD, USA
More information about the fedora-list
mailing list