Showing posts with label samba. Show all posts
Showing posts with label samba. Show all posts

Saturday, July 10, 2010

Redirecting a Samba share to another server

In this post I'll describe how to configure Samba to redirect a share to another server. A typical example when this might be useful is as follows. You have a share, say \\server\work that you need to migrate to new hardware, so that it becomes \\newserver\work. However, you don't want all your users to remember that the files are at a new location. You'd like your users to continue using the old address \\server\work and be transparently redirected to \\newserver\work. This is possible with MS DFS (distributed filesystem) support via msdfs proxy directive. It seems like a more obscure directive not very well documented and described, so I'll try to report my experience with it.

The first thing to do is to enable MS DFS in Samba on the global level by specifying:


host msdfs = true

in the [global] section of smb.conf.

Then in the section for your share, you remove the path directive and insert two MS DFS-related directives, msdfs root and msdfs proxy:


[work]
msdfs root = true
msdfs proxy = \newserver\work

Note a few things about this configuration:
  1. You MUST NOT have the path directive in the share definition
  2. The value of msdfs proxy directive is the new location of the share to redirect to; notice though, that's a single backslash in the beginning of the value, NOT the double backslash you could have expected!

That's all, now \\server\work transparently redirects to \\newserver\work. Clients may need to be rebooted to start working properly with the redirected share. In my experience, clients can't access the share right after the reconfiguration, but it starts working after some time (not sure how much time) or after the client reboots.

Tuesday, October 13, 2009

Samba shares inaccessible after power failure

A test Samba server (domain member with ADS security) suffered a crash due to power failure, and after that its shared became inacessible: when Windows clients tried to access them, password dialog was shown and the correct password was not accepted.

Samba log showed the following:

[2009/10/08 13:22:25, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!

Winbind log showed the following

[2009/10/08 13:13:45, 5] nsswitch/winbindd_user.c:winbindd_getpwnam(353)
  Could not parse domain user: lz

The problem was resolved by removing all *.tdb files in /var/lib/samba.

WARNING. This was a test server, so removing the files were not a problem. If it were a production server, removing windbindd_idmap.tdb would destroy the mapping of Windows and Unix users, and thus all file permissions on Samba shares would be screwed up. On a production server one would try to rescue at least windbindd_idmap.tdb.

Friday, November 07, 2008

Windows 2003 Server cannot access Samba share

We migrated a certain application from a Windows XP workstation to Windows Server 2003 and faced the following issue. The Windows Server 2003 computer could not access a share on a remote Samba server that is running in security = server mode. Attempts to access the remote share resulted in this error message:

\\server is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

The request is not supported.

For various reasons we could not change the Samba server security mode to ADS. A workaround, however, was found here.

On Windows Server, start Local Security Policies, navigate to Local Policies --> Security Options. Open the "Network Security: LAN Manager Authentication Level" setting and set it to "Send LM and NTLM responses".

After that, remote Samba share is accessible. No reboot necessary.

Saturday, October 25, 2008

"Failed to set servicePrincipalNames" Samba error

I was trying to join a Samba server to an Active Directory domain with a standard command:

net -U administrator ads join

Unexpectedly, the command failed with the following message:

Failed to set servicePrincipalNames. 
Please ensure that the DNS domain of this server matches the AD domain, 
Or rejoin with using Domain Admin credentials.
Disabled account for 'SERVERNAME' in realm 'DOMAIN' 

I was puzzled, since DNS domain name was correct, and I was using Domain Admin credentials.

After some searching, I came upon an advice here to check /etc/hosts. And indeed, the file contained an entry created by my distribution (Fedora) setup process which looked like:


SERVER_IP_ADDRESS SERVERNAME

Where SERVERNAME was a short name (without domain). Changing it to

SERVER_IP_ADDRESS SERVERNAME.DOMAIN

or just removing it resolved the issue. Rather weird.

Monday, May 19, 2008

Corrupt Winbind IDMAP database

After a Samba server crashed due to a power failure, several users could no longer access it shares. When access was attempted, password dialog was shown and the correct password was not accepted. Strangely, the problem affected only some users, while others continued to work in Samba shares successfully.

The Samba server's /var/log/messages showed the following errors:

May 19 12:48:05 server winbindd[1929]:   tdb(/var/lib/samba/winbindd_idmap.tdb): 
tdb_rec_read bad magic 0x42424242 at offset=102664
May 19 12:48:05 server winbindd[1929]:   Error storing SID -> ID: Corrupt database

So, the problem was that windbindd_idmap.tdb file was corrupted. In this situation, the only sensible solution is to restore the file from a backup. If you don't have a backup, you are out of luck. Best you can do is remove the corrupted file, but it stores the mapping between Windows and Unix user IDs, and as the result file ownership and permission information on the Samba shares will be screwed up.

Thursday, September 21, 2006

How to configure /etc/krb5.conf for Samba

Recently I've set up a Samba server to be an AD domain member. A question came up: do I need to configure Kerberos? I am using Fedora Core 5 with MIT Kerberos. The answer can be found in Samba docs, but it is scattered around several unrelated parts of the Official Samba Howto and is not easily accessible. In my experience, the answer is as follows:
  • make sure dns_lookup_kdc = true in [libdefaults] section
  • optionally set default_realm in [libdefaults] section to the DNS name of your AD domain. I have a suspicion that this only provides a default for Kerberos command-line tools and is not important for Samba
So, have in your krb5.conf: [libdefaults] dns_lookup_kdc = true default_realm = YOUR.DOMAIN and don't change anything else.