Force Group

Still working on the Samba problem.

Tonight I decided to setup a new file share. Since the [homes] section works, I wanted to see if I could setup a share more like the one I was trying to fix. I followed the same steps, and found that the new one wasn't accessible either. This was actually a good thing, because it told me that the problem could be in the share definition. So, I commented the settings one by one until it worked, trying different combinations.

It turns out that it was the force group setting that was causing the trouble. With it commented, I can access the share just fine. It now works on all the client machines.

The goal of that setting was to have all new files be in the 'users' group so that all of us could access each others' files by default. Testing that will be tomorrow's assignment.

Samba - More Playing Around

So, a couple of days ago, I started working on my Samba problem. In the log file /var/log/samba/log.smbd, I found these error messages repeating about every 30 minues:

[2007/05/22 20:23:14, 0] auth/auth_util.c:create_builtin_administrators(785)
create_builtin_administrators: Failed to create Administrators
[2007/05/22 20:23:14, 0] auth/auth_util.c:create_builtin_users(751)
create_builtin_users: Failed to create Users

Some Google research showed several theories as to why this would happen, although those having trouble didn't seem to be helped much. The most common explanation was that the user database was using the wrong (read: not the best) format. I messed around with the setting a little, to no avail.

Today at work I decided that I didn't have to diagnose and solve this problem. I don't need to file a bug report or try to fix the code. I just want it to work. Therefore, I've decided to uninstall Samba and all of its compainions, delete the configuration files (the entire /etc/samba/ folder), and start over. It only takes about 15 minutes for my entire Samba installation procedure. Why waste time trying to fix it? (Unless of course this doesn't work, and I'm back to the drawing board again.)

Anyway, here goes...

OK, so there's trouble right off the bat. I entered this command to remove the Samba stuff:

sudo apt-get install samba samba-doc libcupsys2 libkrb53 winbind smbclient cupsys-common samba-doc-pdf smbfs

And it also wants to remove the SSH components. I'm guessing it is one of the libraries that has a dependency for SSH. I'll try it without those.

Yup, it was libkrb53. I used this instead with better results:

sudo apt-get remove samba samba-doc libcupsys2 winbind smbclient cupsys-common samba-doc-pdf smbfs samba-common

After that was done, I removed all of the files from /etc/samba/. Is it that easy? Is it gone? I guess I'll try the reinstall.

1. Install Samba
2. Setup Configuration File
3. Setup Other Users
4. The Rest of the Setup

And ... it still doesn't work.

Something interesting though - I added a [homes] section to smb.conf and restarted Samba. Now, I can see and open my home folder via Samba, but still can't get to the files share. So that means Samba is working and the authentication is working.

Oh, and the 'Failed to create' error mentioned above is still showing up in the log.

I just don't get it.

Samba Problem Caused by 7.04 Upgrade

OK, so here's the description of the problem. Since I upgraded my server from Ubuntu Server 6.10 to 7.04, I can't connect to the Samba share from my client machines.

This machine only offers two services Samba and SSH, and SSH works fine.

When I try to connect to the Samba share, I'm asked for a password. If I enter the correct password, I get an error saying that the folder contents could not be displayed. A similar error is displayed from a Win XP client.

Now, here's the weird part, if I enter an invalid password, it asks me again. To me, this means that the client is communicating with the Samba service (the service is running, and there's not a firewall issue), and is validating when the correct password is entered, but it is after that validation that I'm being refused.

My Google searches on Samba problems after an upgrade have not yielded anything, but I'll keep looking.

Booting the Server After Upgrade

You may remember last time that I was unable to boot after upgrade to Ubuntu 7.04. The error was:

Check root=bootarg cat /proc/cmdline
or missing modules, devices: cat /proc/modules ls /dev
ALERT! /dev/disk/by-uuid/7e6ada37-87a7-475b-9a12-53129119ea05 does not exist. Dropping to a shell!

I looked around quite a bit to find a solution. Some suggested that the uuid in /boot/grub/menu.lst didn't match the uuid of the drive. Unfortunately, from the initfs prompt, I couldn't get to the /dev/disk/by-uuid directory.

What I could do was mount the drive:

modprobe ide-disk
modprobe ide-generic
mount -t ext3 /dev/hda1 /root

and edit the grub menu:

chroot /root nano /boot/grub/menu.lst

I tried changing that file to point to a drive rather than a uuid (I can't find page anymore, so no example), but that didn't help. It only removed the uuid from the error message.

Finally, after over two weeks of this, I broke down and reconnected the CD-ROM to the server to boot from the install CD in rescue mode. Regular readers will remember that I don't have an optical drive on this machine, since I didn't think I would need it after installation, and that it requires a low profile drive that is a little pricey. (I may get a DVD burner someday for backups, although today I can't find one to link to.) So, I have to crack open the case and hang a full sized drive off the side of the chassis like this.

I was able to boot to the rescue disk and mount the main drive partition. A quick look in /dev/disk/by-uuid showed that the uuid on the drive did match the one entered in menu.lst and in fstab. So, after all of that work, I was still nowhere.

One more thing to try, this page suggested that I build a new initrd image file with this command:

dpkg-reconfigure linux-image-2.6.20-15-386 (substitute the name of your kernal as found in menu.lst)

And, wouldn't you know it, it worked! I can now boot to the server, and connect via ssh.

Still, there is now a new problem; I can't connect to the Samba share. All of the files are still there and the Samba configuration file haven't changed, but we're getting permission errors. The solution for this will be the subject of a later (hopefully not much later) post.

One more thing, the steps to connect the temporary CD drive reminded me that the BIOS settings still are not saved if the power cable is removed - even after I changed the battery. This is a problem only because the POST hangs on two errors: no keyboard connected and no floppy drive found. I don't know what to do about this, but every time the power goes off (around every three months), I have to reconnect a keyboard and monitor to get the server going again. I may have to take it to the local shop.

Upgrading the File Server to 7.04

After having such great luck upgrading the backup server to 7.04, it's time to do the same to the file server.

At the beginning, things went as smooth as the first time, but when I ran the do-release-command, I was cautioned against using ssh to access the server during the process. The message said that if I continued a 2nd ssh daemon would be started on port 9004. (I have no idea why.) Anyway, since it worked fine the first time, I answered yes to continue. So far, it's still working.

...

I've had to answer a couple of questions about saving config files and such. No worries.

...

Just like last time, the reboot didn't work. I assumed it had something to do with the lack of a keyboard, or maybe the floppy disk setting in BIOS, so I attached a monitor to check. A pretty nasty message said that some long named file wasn't there, and it was dropping to a shell.

Like any well trained IT professional, I decided to power off and on. Now, after the BIOS screen comes and goes, I see "Starting up ... Loading, please wait..." No more disk activity, no change on the screen, nothing. It's hosed.

You don't think it was the ssh thing, do you?

Looks like I have something to work on this weekend.

UPDATE:

If I wait long enough, the error comes up again. Here is is:

Check root=bootarg cat /proc/cmdline
or missing modules, devices: cat /proc/modules ls /dev
ALERT! /dev/disk/by-uuid/7e6ada37-87a7-475b-9a12-53129119ea05 does not exist. Dropping to a shell!

UPDATE 2: The solution for this problem is here.