• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

FC5 samba

Red Squirrel

No Lifer
Does the samba installation that comes with FC5 actually work? if yes, how do I make it work? Every share I make, it keeps saying the path cant be found, but the path is RIGHT THERE, so I dont know why it cant find it. I copied and pasted the share definitions from my old server, so theres no chance of any mistakes in the paths, and yet it keeps saying it cant be found, when I try to access a share. I had this issue in my test environment and ignored it but i realized I may of gotten myself into a big mess by doing this upgrade, if the samba does not even work...
 
Path not found errors are usually due to a problem with nmbd (the "name service"), not smbd. So the share definitions are probably fine, but something else is wrong in the global section of smb.conf. That file is pretty well commented, and the man page is quite exhaustive - figure out what's different between the old and new config, then read up and figure out what to do with it.
 
I even tried replacing the config file with my old one. same story. It's acting as if the path I send my shares to do not exist, but they do. That or it will prompt for a password but not let anyone in. Yes I did smbpasswd -a and readded all the users - wish there was a way to import that db though but its done now. I'm suprised I cant find anything on google on this, since its a pretty big issue. Even with factory settings it does not work.
 
Yeah its running. I can type \\borg from windows and see the shares, but it says network path cannot be found if I try to open any one. (and the paths exist - the share defs were copied from my other file). I even tried doing a mass chmod 777 in the samba folders to see if its a permission issue, and its not even that. The user database is synced with the windows SAM database for the users that need to access shares... basically everything is done for it to work. I've setted up samba before on other distros and never had this problem.


The log has stuff like this in it:

Code:
  ===============================================================
[2006/07/01 15:14:06, 0] lib/util.c:smb_panic2(1566)
  smb_panic(): calling panic action [/usr/share/samba/panic-action 2065]
[2006/07/01 15:14:06, 0] lib/util.c:smb_panic2(1574)
  smb_panic(): action returned status 127
[2006/07/01 15:14:06, 0] lib/util.c:smb_panic2(1576)
  PANIC: internal error
[2006/07/01 15:14:06, 0] lib/util.c:smb_panic2(1584)
  BACKTRACE: 16 stack frames:
   #0 smbd(smb_panic2+0x8a) [0xcfc81a]
   #1 smbd(smb_panic+0x19) [0xcfca79]
   #2 smbd [0xce6952]
   #3 [0x111420]
   #4 smbd(tdb_close+0x17) [0xd12057]
   #5 smbd [0xcd418d]
   #6 smbd [0xcb7b30]
   #7 smbd(pdb_getsampwnam+0x42) [0xcb96d2]
   #8 smbd(local_uid_to_sid+0x149) [0xcb3549]
   #9 smbd(uid_to_sid+0x156) [0xcbc1e6]
   #10 smbd(get_root_nt_token+0xf2) [0xd43d42]
   #11 smbd(svcctl_init_keys+0x28) [0xc058a8]
   #12 smbd(init_registry+0xd4) [0xd8fcf4]
   #13 smbd(main+0x5fa) [0xda2cea]
   #14 /lib/libc.so.6(__libc_start_main+0xdc) [0x9977e4]
   #15 smbd [0xb352f1]
[2006/07/01 15:59:59, 0] passdb/secrets.c:secrets_init(67)
  Failed to open /etc/samba/secrets.tdb
[2006/07/01 15:59:59, 0] passdb/secrets.c:secrets_init(67)
  Failed to open /etc/samba/secrets.tdb
[2006/07/01 15:59:59, 0] passdb/secrets.c:secrets_init(67)
  Failed to open /etc/samba/secrets.tdb
[2006/07/01 15:59:59, 0] passdb/machine_sid.c:Pdb_generate_sam_sid(163)
  pdb_generate_sam_sid: Failed to store generated machine SID.
[2006/07/01 15:59:59, 0] lib/util.c:smb_panic2(1566)
  smb_panic(): calling panic action [/usr/share/samba/panic-action 2412]
[2006/07/01 15:59:59, 0] lib/util.c:smb_panic2(1574)
  smb_panic(): action returned status 127
[2006/07/01 15:59:59, 0] lib/util.c:smb_panic2(1576)
  PANIC: Could not generate a machine SID
  
[2006/07/01 15:59:59, 0] lib/util.c:smb_panic2(1584)
  BACKTRACE: 7 stack frames:
   #0 smbd(smb_panic2+0x8a) [0xe1b81a]
   #1 smbd(smb_panic+0x19) [0xe1ba79]
   #2 smbd(get_global_sam_sid+0x1a7) [0xdc33f7]
   #3 smbd(init_guest_info+0x7b) [0xe62b3b]
   #4 smbd(main+0x505) [0xec1bf5]
   #5 /lib/libc.so.6(__libc_start_main+0xdc) [0x85a7e4]
   #6 smbd [0xc542f1]
[2006/07/01 16:00:17, 0] passdb/secrets.c:secrets_init(67)
  Failed to open /etc/samba/secrets.tdb
[2006/07/01 16:00:17, 0] passdb/secrets.c:secrets_init(67)
  Failed to open /etc/samba/secrets.tdb
[2006/07/01 16:00:17, 0] passdb/secrets.c:secrets_init(67)
  Failed to open /etc/samba/secrets.tdb
[2006/07/01 16:00:17, 0] passdb/machine_sid.c:Pdb_generate_sam_sid(163)
  pdb_generate_sam_sid: Failed to store generated machine SID.
[2006/07/01 16:00:17, 0] lib/util.c:smb_panic2(1566)
  smb_panic(): calling panic action [/usr/share/samba/panic-action 2434]
[2006/07/01 16:00:17, 0] lib/util.c:smb_panic2(1574)
  smb_panic(): action returned status 127
[2006/07/01 16:00:17, 0] lib/util.c:smb_panic2(1576)
  PANIC: Could not generate a machine SID
  
[2006/07/01 16:00:17, 0] lib/util.c:smb_panic2(1584)
  BACKTRACE: 7 stack frames:
   #0 smbd(smb_panic2+0x8a) [0x87b81a]
   #1 smbd(smb_panic+0x19) [0x87ba79]
   #2 smbd(get_global_sam_sid+0x1a7) [0x8233f7]
   #3 smbd(init_guest_info+0x7b) [0x8c2b3b]
   #4 smbd(main+0x505) [0x921bf5]
   #5 /lib/libc.so.6(__libc_start_main+0xdc) [0xb937e4]
   #6 smbd [0x6b42f1]


The logs named after machines around my network are full of access denied... but yet this should not be the case.

Code:
 '/data/samba/public' does not exist or permission denied when connecting to [public] Error was Permission denied
[2006/07/01 16:13:52, 0] smbd/service.c:make_connection_snum(663)
  '/data/samba/public' does not exist or permission denied when connecting to [public] Error was Permission denied
[2006/07/01 16:13:52, 0] smbd/service.c:make_connection_snum(663)
  '/data/samba/public' does not exist or permission denied when connecting to [public] Error was Permission denied
[2006/07/01 16:13:52, 0] smbd/service.c:make_connection_snum(663)
  '/data/samba/public' does not exist or permission denied when connecting to [public] Error was Permission denied
[2006/07/02 10:56:19, 0] smbd/service.c:make_connection_snum(663)
  '/data/samba/shared/auclair' does not exist or permission denied when connecting to [auclair] Error was Permission denied


Is there a new setting maybe I need to change? But I even tried copying the entire smb.conf file to replace the factory one, and still get this issue, so it has to be something outside of this file, at least I would think.
 
IIRC SELinux is enable by default in FC5, are you sure that's not the issue?

I even tried doing a mass chmod 777 in the samba folders to see if its a permission issue, and its not even that.

Never do that, you should _never_ have anything mode 777 on a machine.

The panics are smbd crashing, I have no idea why that would happen.

Failed to open /etc/samba/secrets.tdb

Does that file exist?
 
yeah secrets.tdb exists, but I did rename it to see if it was corrupted, and let samba recreate it, but no go. I also disabled SElinux, well at least based on the docs, its disabled. I ran a command and a there was a checkbox to disabled. I also disabled ipchains.

I have a feeling samba is simply broken in this version, I remember installing FC5 in a VM and had the exact same issues, I should not have ignored them, but based on my research its not a known issue...
 
I just realized something, since I'm not on a domain, could this be an issue with this newer version? Maybe it only supports domain environments. Does it require all the machines to have a trust account? If yes, is there a way around this? I want to be able to plug in any machine to the network, like a friend's laptop and be able to access whatever is set to public.
 
The thing that baffles me the most is that if I copy my old config file to replace the curent, I still get the same issue. I'm running yum update right now... it might fix all the problems i'm getting...

edit: yum update samba did not fix it, an actual yum update is about 300 megs, something this size scares me as it may start messing with too much stuff so I rather not try it.
 
Like Nothinman, I find it highly unlikely that Samba is out-and-out broken in an FC release. It's much more likely that something is misconfigured, either in smb.conf or somewhere else that affects samba. Also, it should not be surprising that your old config doesn't work in the new system. Debian and FC are radically different in their philosophies and practices for software configuration. While the actual syntax of smb.conf may be the same, there are all kinds of places where file paths, permissions, or options could differ. I would not even have bothered trying the old config straight up.

At this point, my advice would be to reinstall Samba from the ground up, starting with very simple configurations and checking both that it works and that you understand what it's doing. Specifically,

1) Remove every trace of the samba RPM's from the system. That means the binaries, configuration files, options in /etc/sysconfig/defaults, whatever...

2) Reinstall the FC RPM's. Don't even configure anything in smb.conf, just check to make sure you don't get any weird errors from the installation.

3) Create a very simple samba configuration - so simple it's not even useful. Comment out all the share definitions. All that should be configured for starters is the default workgroup (stick with the default "WORKGROUP"), logging, and security=user. Restart samba and check your logs for errors. Fix them if there are any.

4) Get your name service sorted out. Change the workgroup to whatever your actual workgroup is and adjust the settings for things like WINS and masters appropriately (i.e. read about them first). Make sure that your client machines can ping the samba server by IP, by DNS name, and by SMB name. If you get here, you're highly unlikely to have any serious problems afterwards. Just like in "real" Windows networking many, many problems in Samba ultimately come from broken name resolution at some level.

5) Set up a very simple share - just one, not your entire previous setup. One share, one owner. Check to see that you can log in with that username and access the share. Keep in mind while you're testing that Windows machines have the habit of caching your credentials. If you're constantly fiddling with your configuration (especially authentication stuff), make sure you clear those cached credentials before testing again.

6) Get the rest of your shares set up.

Except for the very simplest configurations, Samba is non-trivial to set up. You're not going to get anywhere by reflexively whacking away at the various configuration options and hoping they work. Work systematically, from the bottom up.
 
Samba was in fact not broken... SE linux is a POS that has to be disabled a few times. (I had it disabled, but aperently not completely)

This thread explains it all: http://www.iceteks.com/forums/index.php?showtopic=4420&st=0&

I simply put selinux=0 as a kernal parameter... everything magically works now. Still have some issues (like procmail not generating a master log, only a per user one if I specify in user's .procmailrc) but the worse is fixed, at least. Funny since I kept running into googled iinfo about disabling SE_linux but I had followed previous instructions to disable it, but it also had to be done at the kernel bootup process, which I just found now.
 
Also, it should not be surprising that your old config doesn't work in the new system. Debian and FC are radically different in their philosophies and practices for software configuration. While the actual syntax of smb.conf may be the same, there are all kinds of places where file paths, permissions, or options could differ. I would not even have bothered trying the old config straight up.

Not really, the only thing with paths in my smb.conf here is the log directory and the shares themselves. The rest of them are compiled defaults and should work unless he explicitly changed them.
 
Yeah I double checked any paths when I migrated the file. When I saw it did not work, I restored the default then only copied and pasted share defs. But as it turns out its SE linux that spoiled the party.
 
SELinux is actually pretty damn cool if you take the time to understand it. It is complicated, though, there's no denying that. I would think that the problem in your case is that the files samba was trying to access weren't properly labelled for use with SELinux. In SELinux-land, there's more to a file than just its permissions - it has label(s) saying what kind of file it is, like "system configuration file" or "user home file" (though the real label names are more terse). Your files from Debian (a non-SELinux system by default) didn't have those labels, and thus Samba was prevented from touching them by the SELinux kernel code, because they weren't marked as the kind of file Samba was allowed access to. Pretty cool really - if Samba were compromised and tricked into accessing files elsewhere on your system (like a password file), it would be stopped in the same way. If you want to get Samba working with SELinux enabled (which is really a pretty good idea on a non-private server) you'll want to look into "relabelling" those homedir files appropriately. FC includes some tools to do this, IIRC.
 
Yeah I double checked any paths when I migrated the file. When I saw it did not work, I restored the default then only copied and pasted share defs. But as it turns out its SE linux that spoiled the party.

SELinux is fine, if you didn't want it why didn't you disable it during installation?
 
Obviously you didn't. I don't have an FC5 box handy but I do know that when I installed it and set SELinux to warn only it did just that. FC5 is the first release with SELinux enabled by default, they wouldn't miss a huge thing like not being able to disable it in the installer.
 
Back
Top