Half way to a working Samba share, but I'm missing something...

[John Collier]

OK, I have recently upgraded my little Linux box to the latest Fedora Core 2. With it came an upgrade to Samba to version 3.0.

I have been working with getting Samba configured to share out a partition on my little box for the Windoze machines on my home network. So far, I have finally been able to get the M$ machines to map a drive to this share, but I have been unable to get them to write to this share.

I am sure that the answer to this has to be permission related, but even using resources such as http://hr.uoregon.edu/davidrl/samba.html (which got me closer than anything else I have seen) and the suggestion from this thread http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=212043 I am still not able to make this work.

When I try a 'testparm', I get the following output:

Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[DOS]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

# Global parameters
[global]
workgroup = {our_home_workgroup}
server string = Samba Server
security = SHARE
password server = None
guest account = greywizzard
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
printcap name = /etc/printcap
dns proxy = No
wins support = Yes
guest ok = Yes
hosts allow = 192.168.1., 192.168.2., #127.
hide unreadable = Yes

[homes]
comment = Home Directories
read only = No
browseable = No

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No

[DOS]
comment = Remote Windows Storage
path = /DOS
read only = No

The only thing that I see right now is that there seems to be a line in that output that doesn't match the config file in the smb.conf. The last section in the config file actually reads:

[DOS]
comment = Remote Windows Storage
path = /DOS
writeable = yes
guest ok = yes


Is that what is stopping me? If so, how do I get that to pass the 'testparm' and, consequently get sent to Samba?

If that isn't it, what have I most likely overlooked? I'm sure it is something quite simple, but I have been staring at this for too long.


Please help!


Thanks,
John

[Stuart Browne]

Dumb question. Does the user 'greywizzard' have write permissions to '/DOS' ?

I am suprised that the 'guest ok = Yes' didn't show up in the 'testparm'. A quick test here shows that it should. Which 'smb.conf' file did you modify? '/etc/samba/smb.conf' ?

'read only = no' and 'writeable = yes' are the same option, just from reverse perspectives.

[John Collier]

Stuart,

You know as well as I do that there are no dumb question. Funny questions, yes, but not dumb ones.

You mention that you don't see the 'guest ok = Yes' in the 'testparm' output as you would expect. With all due respect, I ask you to look again. It is in there. It was one of the parameters that I specifically looked for myself. I was actually hoping that would be my miracle cure at one point. Silly me, huh?

As far as what 'smbd.conf' file I am dealing with, I took the output from the 'testparm' command to determine the correct file to edit. The first line of the output gave the full path that I needed, in this case it is /etc/samba/smb.conf. (a quick search of the box proved that this is actually the only smbd.conf as well).

Now, back to your supposed dumb question. My first response to that in my own mind was 'OF COURSE!!', but then I decided to look again to be sure. What I found was very unexpected.

I'm not sitting at the box right this moment and I looked at this last night through eyes that were very heavy with sleep sand so I don't remember the exact permission string on it but it went something like:
drwxr-x--x root root {partition_size} {some_time_stamp} Dec 31, 1969 /DOS

Remember that this may not be completely accurate, but there is one thing that I am sure of and that is the date that it has on it. I am also sure that I was not able to 'chmod' the file to change the permissions AT ALL for this partition. Logic dictates that this must be the base cause for my current problem, but this brings me to another couple of questions.

Why would the file show the date Dec31, 1969? Why isn't it possible to change the permissions on it? How do I solve this?


Input from all will be appreciated...

[Stuart Browne]

John,

The 'guest ok' stuff was because of your paste from 'testparm':

[DOS]
comment = Remote Windows Storage
path = /DOS
read only = No

I absolutely agree that your 'smb.conf' has the correct 'guest ok = yes' string (as the second paste shows), but the 'testparm' didn't show it. Thus my concern, and wondering which 'smb.conf' you modified.

In any case, not being able to change permissions on a directory.. Is it a mount point? If it is, you may need to unmount it first (although you shouldn't have to). It depends on what the filesystem is (nfs? smbfs? They can cause funny behaviour on mount-point directories).

If it's just a flat directory, and you can't change permissions... Well, two things to look into. 1) is something controlling the directory? ('lsof | grep ...' is your friend here). I doubt it is this however. 2) file-system funnies. Time for an 'fsck'.

As for the date, it points to an fsck-needed fix. Can you 'touch /DOS' and it's time changes?

[John Collier]

Stuart,

Sorry for the long delay in getting back to this, but since it is a personal project and not a business-critical issue it has not been extremely high on my priority list. Other things in life have taken higher priority (such as my daughter). Hope you understand.

Anyway, I have had a chance to do a little playing with this and have made some interesting discoveries.

When I take the box into single user mode and umount the partition from the /DOS mount point I suddenly see the permissions that I expected to see. Without the partition mounted, everybody has full access to the /DOS directory (since that is all that it is at that point) in the root file system. That makes me feel better because it means that I really did to the chmod on it that I thought I did before.

The interesting thing is that when I then mount the desired disk partition under that same point I suddenly end up with a permission structure that basically only lets root have full access. Removing the mount point and rebuilding it shows me that what I am seeing in the way of permissions is the default permissions for a new file and/or folder. What is even more interesting is that it WILL NOT let me change the permissions or the owner of this when the partition is mounted there.

I know that there has to be a way to make this work and I am sure that I am missing something pretty basic, but since I don't have much hands on experience with this type of situation, I am at a loss on what the next logical step is.

I guess I could just log every user in as root, but I would prefer not to do that.

Any words of wisdom?


Thanks again,
John


P.S. Not that it really matters in the grand scheme of life, but if you will look at the third from the last line in the Global Parameters section of the testparm output, you will see the guest statement that we referred to earlier.

[Stuart Browne]

John,

Guest-ok: oh yea.. global guest-ok.. ok, didn't see that.

As for the other.. Right. Ok. It would appear as if you're mounting a filesystem that knows nothing about, nor honors user permissions (NTFS? FAT32? some-other-POS-filesystem-type? :P).

When mounting the filesystem, the options uid=X,uid=X as well as a umask=XYZ to force permissions a little more open.

As you're forcing guest usage for the share to greywizzard, you could uid= and be done with it.

(See 'man mount' for the appropriate options for the filesystem type.

[John Collier]

Stuart,

I think I may have made one of the bigger 'Nube' assumptions in this situation that I could have made and it is probably causing me all of my headaches.

Although you didn't just come right out and say it, I get the feeling that I most likely don't have to have a FAT32 partition to share out to Microsloth machines. The tone of your response seems to indicate that Samba will let me share out native Linux file systems to Microsloth machines and handle the translation of the M$ disk calls to a Linux format. Am I correct on this assumption?

If so, then the easiest way for me to correct this would be for me to simply reformat that partition in something along the lines of ext3 and move on (besides, I think that the Linux file systems are a bit more efficient anyway).

For some reason, I just thought that if I was going to be sharing out a partition on my Linux box I would have to create it in a format that the M$ machines would be able to read. Thinking back on that, it really doesn't make that much sense right now. Linux is much smarter in so many ways, it just figures that Samba would be able to do that translation. I'll bet that it is even in the Docs somewhere and I just didn't read or understand it when I saw it.

I will still look into the man pages for mount and see if I can learn something there, but I would really like to know if I can simply reformat that partition and still share it out.

Thanks for all your help and patience on this. I really thought I had a better handle on the situation when I started this thread...


John

[Stuart Browne · Accepted solution]

John,

If you were on the same machine (dual-boot), then using a FAT32 is the easiest way to share data between reboots, but in a Samba environment, it isn't.

The whole point of samba is to share local data to machines that don't understand the local format.

So yes. You can have your local file system in whatever format you want (xfs, reiserfs, ext2/3, jfs, etc. etc.), and Samba will do all the translation stuff.

The windows machines talk to Samba, requesting information in LanMan format, so the actual Windows IO calls never touch the Linux box a native format.

The same thing happens in any sort of file-sharing environment: The end filesystem does not have to be the same as the reqesting. The software/daemons in the middle is what do all that sort of coversation/translating.

Have fun ;)

[Bill Thorsteinson]

MSDos ish partions don't have the concepts
of ownership that Unix has. The mount command
can be used to set ownershup and permissions
in a global manner for the disk.

Samba will handle the I/O transitions required to use a ext3 or other Unix partition type.
I would recommend you do so. This allows you
to restrict access by user and group to specific
files and directories if required.

Samba does a little hacking on the execute permissions to map the MSDos file access bits.

The Samba 3.0 release also handles mapping
Windows groups to Unix grouops.

The Samba documentation is extensive and good.

[Steven E. Protter]

I would suggest the following diagnostic approach:

1) Make sure the users that need to map are in both linux and windows. If you are connecting into a windows pdc, fine, go over that doc. If not, makes sure every user exists on linux has a current smbpasswd -a run on it.

2) Go to the samba log smb%m.log on linux. tail -f it. connect, try and connect, then write adn see wht the error is. Report it or act on it.

SEP