Re: [BLUG] Certain XP machines won't connect to Samba share

Hmmm, you don't have "security" defined, so the default is "security =
user". Try changing it to "security = share" (that is, add a line that
says that under the [global] section) to see if the behavior changes.

The "map to guest" setting might be worth playing with, if you prefer
to leave it on "security = user" or "security = share" doesn't yield
you any better behavior.

<blockquote>
Note that this parameter is needed to set up "Guest" share
services when using security modes other than share and
server. This is because in these modes the name of the
resource being requested is not sent to the server until after
the server has successfully authenticated the client so the
server cannot make authentication decisions at the correct
time (connection to the share) for "Guest" shares. This param�
eter is not useful with security = server as in this security
mode no information is returned about whether a user logon
failed due to a bad username or bad password, the same error
is returned from a modern server in both cases.
</blockquote>

If you run a "man smb.conf" you'll get to see the reason Samba causes
headaches, the settings are organized alphabetically and thoroughly
explained.

Enjoy. :-)

Simón

P.S. The XP machines that do work, even if they log in automatically,
MUST have a username; do you know what that username is?

On Wed, Sep 3, 2008 at 5:15 PM, Mark Warner <markwarner1954@att.net> wrote:
>
> Here's a copy of the existing smb.conf:
>

*snip!*

>
> To my untrained eyes, nothing looks amiss. Then again, I dunno nuthin'.
>
> What I don't get is why all the Windows machines in the building (mix of W2K
> and XPp) *except* these two can see and connect to this share. The only
> thing these two have in common (that I can come up with) is that they have
> passworded Windows logins. All the other machines just boot the user
> straight to his desktop.
>
> --
> Mark Warner

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] Certain XP machines won't connect to Samba share

Simón Ruiz wrote:
> Mark,
>
> The Samba server's configuration file is located at
> /etc/samba/smb.conf (usually).
>
> I hate to say this, but you'll likely need to get your hands dirty in there.
>
> I've had enough Samba-induced migraines in the past year to bring down
> a herd of flying cats, so I don't envy you this task.
>
> The options that will most likely be relevant will be at the top under
> the [global] tag or all the way at the end under the [share name] tag.
>
> Some options you may want to make sure are set right (google is your
> friend for specifics):
> [global]
> security = share (I think)
> [sharebyshare]
> guest ok = Yes (I think)
>
> Let us know what you come up with.

Here's a copy of the existing smb.conf:

;*******************section global*****************
[global]

# Do something sensible when Samba crashes: mail the admin a backtrace
panic action = /usr/share/samba/panic-action %d
printing = cups
server string = %h server (Samba %v)
hosts allow = 192.168.0. 192.168.1. 192.168.2. 192.168.79. 127. 10.0.0.
10.1.1.
socket options = IPTOS_LOWDELAY TCP_NODELAY
log level = 1
dead time = 15
wins support = yes
hide unreadable = yes
passdb backend = tdbsam
dns proxy = no
host msdfs = no
max log size = 1000
map to guest = Bad Password
restrict anonymous = no
domain master = no
preferred master = no
max protocol = NT
ldap ssl = No
server signing = Auto
oplocks = No
level2 oplocks = No
;*******************section IMC*****************
[Shared]
path = /home/IMC/Shared
guest ok = yes
read only = no
;*******************section homes*****************
[homes]
comment = Home Directories
browseable = no
read only = no
;*******************section printers*****************
[printers]
comment = All Printers
path = /tmp
browseable = no
printable = yes
guest ok = yes
create mask = 0700
__________________________

To my untrained eyes, nothing looks amiss. Then again, I dunno nuthin'.

What I don't get is why all the Windows machines in the building (mix of
W2K and XPp) *except* these two can see and connect to this share. The
only thing these two have in common (that I can come up with) is that
they have passworded Windows logins. All the other machines just boot
the user straight to his desktop.

--
Mark Warner
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] Certain XP machines won't connect to Samba share

Simón Ruiz wrote:
> Mark,
>
> The Samba server's configuration file is located at
> /etc/samba/smb.conf (usually).
>
> I hate to say this, but you'll likely need to get your hands dirty in there.

I'm not scared of that, and usually can grok enough to at least not do
any damage, but knowing where to go and what to do when I get there is
where I come up short.

> I've had enough Samba-induced migraines in the past year to bring down
> a herd of flying cats, so I don't envy you this task.
>
> The options that will most likely be relevant will be at the top under
> the [global] tag or all the way at the end under the [share name] tag.
>
> Some options you may want to make sure are set right (google is your
> friend for specifics):
> [global]
> security = share (I think)
> [sharebyshare]
> guest ok = Yes (I think)
>
> Let us know what you come up with.

Excellent. That gives me a starting point, at least.

> P.S. After modifying /etc/samba/smb.conf run the "testparm" command to
> make sure it's a good config file, and an "/etc/init.d/samba reload"
> will apply the new settings.

Thanks for that. Left to my own devices, I wouldn't have even thought of
restarting Samba.

> P.P.S. Do you know how to edit a system configuration file?

If you mean do I know how to go root and edit a text file (such as
sources.list or xorg.conf), yes, that much I can handle. Not *much* more
than that, though. :-)

Thanks for the follow-up. I'll post back with the result, one way or the
other.

--
Mark Warner
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] Certain XP machines won't connect to Samba share

Mark,

The Samba server's configuration file is located at
/etc/samba/smb.conf (usually).

I hate to say this, but you'll likely need to get your hands dirty in there.

I've had enough Samba-induced migraines in the past year to bring down
a herd of flying cats, so I don't envy you this task.

The options that will most likely be relevant will be at the top under
the [global] tag or all the way at the end under the [share name] tag.

Some options you may want to make sure are set right (google is your
friend for specifics):
[global]
security = share (I think)
[sharebyshare]
guest ok = Yes (I think)

Let us know what you come up with.

Simón

P.S. After modifying /etc/samba/smb.conf run the "testparm" command to
make sure it's a good config file, and an "/etc/init.d/samba reload"
will apply the new settings.
P.P.S. Do you know how to edit a system configuration file?

On Wed, Sep 3, 2008 at 3:18 PM, Mark Warner <markwarner1954@att.net> wrote:
>
> A while back I set up a MEPIS 7 (essentially Debian Etch) machine as a
> shared file server on my workplace network. Just a place to store and share
> files. Simple setup -- created a large partition, linked it to the Shared
> directory in /home, and plugged it in to the network. Works great. Everybody
> has full read/write, and it makes a good central repository. Except...
>
> Of the sixteen or so workstations, two can't hook up to it. They are both XP
> Pro machines. The share isn't detected automagically in Network Places, and
> typing in the share path directly results in a permissions error. It's been
> this way for since I set this up, and I've not been able to figure it out.
> Then I realized something: I believe these are the only two machines that
> have a passworded user logon. All the others are blank passwords. That
> kinda/sorta makes sense, based on what I'm seeing when I try to connect to
> the share.
>
> My problem is I don't know where to go from here. Don't know if there's
> anything I can change on the server, or if there's something I can change on
> the individual machines. Any help/pointers/handholding appreciated.
> Understand that I'm a barely competent Linux *user*, not an administrator by
> any means. If you have any suggestions, talk baby talk to me.
>
> --
> Mark Warner
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug
>

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] changing filesystem UUIDs (was: Amarok)

On Wed, Sep 3, 2008 at 11:58 AM, Steven Black <blacks@indiana.edu> wrote:
> In Linux you can use the 'mlabel' command (part of mtools) to change
> the serial number of a FAT filesystem. You can use -n to generate a new
> random label, or -N to specify your own 8 digit hexadecimal number.

Hah, that's funny.

I figured out that I needed to use mlabel to change the filesystem
label from "CAVALRY", or whatever; I did NOT think to use it modify
the serial number and thus the perceived UUID.

Ya learn something new everyday. Thanks!

Simón

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

[BLUG] Certain XP machines won't connect to Samba share

A while back I set up a MEPIS 7 (essentially Debian Etch) machine as a
shared file server on my workplace network. Just a place to store and
share files. Simple setup -- created a large partition, linked it to the
Shared directory in /home, and plugged it in to the network. Works
great. Everybody has full read/write, and it makes a good central
repository. Except...

Of the sixteen or so workstations, two can't hook up to it. They are
both XP Pro machines. The share isn't detected automagically in Network
Places, and typing in the share path directly results in a permissions
error. It's been this way for since I set this up, and I've not been
able to figure it out. Then I realized something: I believe these are
the only two machines that have a passworded user logon. All the others
are blank passwords. That kinda/sorta makes sense, based on what I'm
seeing when I try to connect to the share.

My problem is I don't know where to go from here. Don't know if there's
anything I can change on the server, or if there's something I can
change on the individual machines. Any help/pointers/handholding
appreciated. Understand that I'm a barely competent Linux *user*, not an
administrator by any means. If you have any suggestions, talk baby talk
to me.

--
Mark Warner
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] Amarok

On Wed, Sep 3, 2008 at 10:14 AM, Steven Black <blacks@indiana.edu> wrote:

On Tue, Sep 02, 2008 at 12:55:42PM -0600, Abhishek Kulkarni wrote:
> I would possibly rely on "uname -m". I have never gotten 'uname -p' to show
> either x86 or i386 on Ubuntu. For some reasons, it just says "unknown".
> It's a bug with either Ubuntu or coreutils which noone seems to keen to fix.

Sorry. I actually meant -m. That was a typo on my part.

The processor, like the hardware platform, is unknowable in Linux. This
is a trait of the underlying PC platform. You can never really know what
type of CPU you are using. Modern x86 CPUs have specific calls to get
this information, but Linux still runs on 386-class machines and you do
not want to know the kinds of hoops people needed to jump through to try
to get the processor class earlier on.

Steven,

Thanks for the detailed explanation.
Yes, the information has to be exported by the kernel for uname to report it correctly. I suspect it might be a sysconf parameter, if not an ioctl, using which uname determines the processor type. It might not be fair enough to deem it as a bug, but most enterprise distributions get their act right when it comes to this. I have often seen broken programs relying on the processor type information output.
 

I know, now you're saying, "but it is easily available now, just
check /proc/cpuinfo". Here you have to remember that the entire /proc
filesystem is optional, as well as that the format of /proc/cpuinfo
varies by architecture. Non-x86 /proc/cpuinfo files look significantly
different.

Good point, procfs is optional. IMO, programs cannot be made to can rely on parsing cpuinfo whose format can change any time.

 -- Abhishek
 

Of course, if modern Linux kernels have an ioctl to query the processor
type in a clean, reliable method that works on other architectures, then
you should file a bug.

Cheers,

--
Steven Black <blacks@indiana.edu> / KeyID: 8596FA8E
Fingerprint: 108C 089C EFA4 832C BF07  78C2 DE71 5433 8596 FA8E

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIvrfS3nFUM4WW+o4RAueaAJ9OH65IUZtibRYJq7mO4CnunPNcvgCgoeOd
NISzY1eTTjO9mzwQ7LcGq2k=
=nHT9
-----END PGP SIGNATURE-----

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] Amarok

On Tue, Sep 02, 2008 at 12:55:42PM -0600, Abhishek Kulkarni wrote:
> I would possibly rely on "uname -m". I have never gotten 'uname -p' to show
> either x86 or i386 on Ubuntu. For some reasons, it just says "unknown".
> It's a bug with either Ubuntu or coreutils which noone seems to keen to fix.

Sorry. I actually meant -m. That was a typo on my part.

The processor, like the hardware platform, is unknowable in Linux. This
is a trait of the underlying PC platform. You can never really know what
type of CPU you are using. Modern x86 CPUs have specific calls to get
this information, but Linux still runs on 386-class machines and you do
not want to know the kinds of hoops people needed to jump through to try
to get the processor class earlier on.

I know, now you're saying, "but it is easily available now, just
check /proc/cpuinfo". Here you have to remember that the entire /proc
filesystem is optional, as well as that the format of /proc/cpuinfo
varies by architecture. Non-x86 /proc/cpuinfo files look significantly
different.

Of course, if modern Linux kernels have an ioctl to query the processor
type in a clean, reliable method that works on other architectures, then
you should file a bug.

Cheers,

--
Steven Black <blacks@indiana.edu> / KeyID: 8596FA8E
Fingerprint: 108C 089C EFA4 832C BF07 78C2 DE71 5433 8596 FA8E

Re: [BLUG] changing filesystem UUIDs (was: Amarok)

On Tue, Sep 02, 2008 at 03:06:51PM -0400, Simón Ruiz wrote:
> Ummm, well, UUIDs are funny things.
>
> For one thing, taking the image of a partition and restoring that
> partition on any other media will have the effect of creating a
> filesystem with the same UUID.
>
> This is GREAT if you're taking an Ubuntu image from one machine and
> moving it to another, as your filesystems will have the same UUID and
> thus the mounting will work right.

If you need to change the UUIDs on a Linux ext2/ext3 filesystem, you can
use tune2fs with -U. You can set it to specific UUIDs, you can clear
it, or set it to a generated UUID (either random or based on the time).
Check the man page on 'tune2fs' for details.

> HOWEVER, just as I use images to save time installing a large number
> of machines; it seems that some external hard drive manufacturers have
> taken to using images to save time slapping the read me files onto all
> their hard drives.
>
> I learned this when my computer wouldn't mount both my brand new 1TB
> USB drive and the one my father bought at the same time, same place;
> it thought of them as the same hard drive, since the UUIDs were
> identical.

If this was a FAT filesystem (because it had the readme from the
manufacturer on it) then this would be expected for a number of reasons.
FAT filesystems don't use a UUID, they use a *much* shorter serial
number (64 bits), and it has had a long history of not being set in any
sort of reliable or unique manner. (Third party programs were known to
only use half of it, and clear the other half.) This was due in part
to the small size of the number, as well as the fact that Microsoft's
serial number algorithm was totally undocumented, which meant people
couldn't reproduce it, which lead to people using a simpler method.

In Linux you can use the 'mlabel' command (part of mtools) to change
the serial number of a FAT filesystem. You can use -n to generate a new
random label, or -N to specify your own 8 digit hexadecimal number.

--
Steven Black <blacks@indiana.edu> / KeyID: 8596FA8E
Fingerprint: 108C 089C EFA4 832C BF07 78C2 DE71 5433 8596 FA8E