For those who have been following the issues around Samba suddenly breaking upon upgrade, I’ve now got to the bottom of it.
I’ve updated the original post with details, so if you wish to leave comments, please leave them on that post.
Promise NS4300N
I decided to buy a NAS and remove the disks from my home server.
I didn’t want to spend too much money, since this was one of those non-essential projects. But equally, I didn’t want to spend too little and get something that would break and destroy all my data with it. Eventually I decided upon a Promise SmartStor NS4300N.
It had all the features I wanted, including:
So how did it shape up?
The build quality was relatively poor. It’s made from thin plastic and feels flimsy. The disk caddies are incredibly flimsy and flexible, and I felt nervous even handling them; but this didn’t matter because I planned to assemble it and leave it alone.
It wasn’t exactly quiet either. There is an 80mm fan for the disks and a 40mm fan for the internal PSU. The 80mm fan only spins when the disks are hot but it is very noisy when it does so. The 40mm fan is constant but not so loud. And of course there’s the sound of four hard disks, which varies depending on make and model. Overall, it’s probably quieter than a standard computer, but you wouldn’t want to sleep with it in your bedroom.
It’s not a problem for me because I’m putting it in the loft.
The initial setup wasn’t as straightforward as I thought it could (should?) have been, especially for beginners. But it wasn’t really much trouble to set up a RAID5 array with 4 x 500GB disks and format it, for a total of 1.4TB.
More confusing, perhaps, was the selection of different protocols and the layout for setting up users, shares and permissions.
I wanted to set up two shares, public and private and set public to be world-readable (for my media centre) and private to be accessible only by me. If you create these accounts on the NAS, it’s simple enough to tick the boxes and set the desired permissions on Windows (SMB/CIFS) shares.
But NFS was a different kettle of fish. No user-level permissions are available on the NAS for NFS, and the only control you get is a list of allowed IP addresses. By default the NAS says it allows *.*.*.* but I found that this didn’t let anyone in. Adding real IP addresses to the list worked.
However, I found that when you have data shared both as NFS and SMB/CIFS, the permissions go out of the window and are not respected at all. An unauthenticated guest user was able to read and delete files from my private share.
Performance was far worse than I had expected.
With the NAS mounted on my PC via NFS, it would only manage 4.8MB/s sustained write rate, and 13.5MB/s sustained read rate. That’s significantly worse than the sustained 30MB/s I used to get with the same disks in the server, as a Linux software RAID array. On top of that, writing at this speed tied up my computer’s quad-core CPU 100% with IOWait.
With the NAS mounted on the same PC via SMB, it was able to write sustained at 9.2MB/s.
This is really quite poor, given that the same set of disks when connected directly into the server with SATA could write at some 35MB/s.
It depends on your usage though – if you simply want to play music and videos from the NAS then 10MB/s is fine, even for high definition. However I use mine for large backups and I don’t want to wait almost ten times longer for the backups to complete.
However, it didn’t cut the mustard with me, so I sent it back. I’ve now returned to my original system with the four disks hosted in the server. It’s fast and the permissions work fine – the downside is that I have to keep a large, noisy ATX tower case and can’t switch to an Intel Atom solution 
I have a samba fileserver which has been happily running for a couple of years with identical config but on different versions of samba, and on Fedora and CentOS.
The latest incarnation was running samba 3.2.11.
But the other day, my samba package was upgraded to 3.4.1
Samba shares on the server immediately stopped working and access is immediately denied to all users.
I looked at the config and nothing has changed during the upgrade.
I looked at the logs and no access attempts are recorded; no errors are logged.
I noticed that the new template config file is a little different from previous versions, so I made the necessary changes and migrated my config to the new file. No change to samba’s behaviour at all.
For a while I wondered if I had a rogue samba server on my network, but stopping my samba service causes requests to time out rather than be denied. So it’s definitely my samba daemon that’s responding, but goodness knows why it behaving like this.
Restarting samba puts the following in the log file:
[2009/10/02 10:33:54, 0] smbd/server.c:1065(main) smbd version 3.4.1-0.41.fc11 started. Copyright Andrew Tridgell and the Samba Team 1992-2009 [2009/10/02 10:33:54, 0] smbd/server.c:457(smbd_open_one_socket) smbd_open_once_socket: open_socket_in: Address already in use [2009/10/02 10:33:54, 0] smbd/server.c:457(smbd_open_one_socket) smbd_open_once_socket: open_socket_in: Address already in use
I will keep hunting until I find what’s caused this. Unfortunately I can’t watch any of my recorded TV programmes until then!
I’ll post back here when I’ve tracked it down.
Update: I managed to get Samba working again. Sort of. This is a snippet from my now-working smb.conf:
# ----------------------- Standalone Server Options ------------------------ # # Scurity can be set to user, share(deprecated) or server(deprecated) # # Backend to store user information in. New installations should # use either tdbsam or ldapsam. smbpasswd is available for backwards # compatibility. tdbsam requires no further configuration. security = user # passdb backend = tdbsam passdb backend = smbpasswd
As you can see, I simply reverted to the older smbpasswd authentication after yum upgraded Samba and switched to tdbsam and my shares magically sprung back to life. It’s a shame, because I don’t like going backwards. I like going forwards – hence I run Fedora.
I can confirm that this “fix” works with the latest version of Samba at the time of writing – version 3.4.2.
So despite the claim that tdbsam requires no extra configuration, clearly there’s more to it than that. I will once again post back here when I’ve found a way to enable tdbsam without breaking everything. 
In this guide, we will set up your home Linux server to share files in a Windows-friendly format. This is ideal for interacting with Windows PCs on your network, or for generic appliances such as media streaming boxes.
First we install Samba:
[root@zeus ~]# yum install samba
Before we configure Samba, you need to think about who is going to need access to this. For an enterprise solution, clearly you’ll need some fancy authentication backend. For a home situation, it’s easier to set up a handful of users on your local system. Let’s assume you want to set up access for your wife, Sue.
[root@zeus ~]# useradd sue
[root@zeus ~]# passwd sue
So now Sue is set up on the server and has a password. Now we need to tell Samba that it’s OK to let system users get access to files. Open the file /etc/samba/smbusers. It should already have a couple of entries in, but you will need to add one for each user you want to use the file shares.
# Unix_name = SMB_name1 SMB_name2 ...
root = administrator admin
nobody = guest pcguest smbguest
sue = sue
tvuser = tvuser
We back up and open the Samba config file for editing:
[root@zeus ~]# cp /etc/samba/smb.conf /etc/samba/smb.conf.old
[root@zeus ~]# vim /etc/samba/smb.conf
Delete all the contents of smb.conf. For now just add the contents of the global section below, but don’t close your editor yet – we need to define the shares.
[global]
dns proxy = no
log file = /var/log/samba/%m.log
cups options = raw
server string = Samba Server
socket options = TCP_NODELAY IPTOS_THROUGHPUT
username map = /etc/samba/smbusers
hosts allow = 192.168.0. 127.
max log size = 50
Now for some examples of how to define shares. The homes example automatically connects each user to their home directory, e.g. /home/sue. If you want this, keep it. If you don’t use your Linux home directories, don’t bother adding this section.
[homes]
comment = Home Directories
browseable = no
writeable = yes
This next one is an example of a media share for a TV streaming box or similar. All users can read it; only sue can write to it.
[media]
path = /media/public
writeable = yes
public = yes
write list = sue
This one is a private share only accessible by sue
[private]
path = /media/private
writeable = yes
valid users = sue
After you’ve defined your shares, save the config, start the service and set it to run on boot
[root@zeus ~]# service smb start
[root@zeus ~]# chkconfig smb on