[Samba] Samba Migration
LLLActive at GMX.Net
LLLActive at GMX.Net
Sun Jan 15 15:00:40 GMT 2006
I have a Samba system running on a standard purchased SuSE Linux 9.3
box. I want to transfer the data to a new Samba running on a standard
Suse Linux 10.0 purchased box version, on a x86_64 cluster platform. The
new configuration is as follows:
I have one central SuSE Linux 10.0 server cluster for all data. It
exports as NFS-Server several shares to a number of NFS-Clients. (The
NFS-Clinets will also be clusters with heartbeat; one for Samba, another
for Apache, another for ERP). At present, the Samba server, for eg.
receives a NFS-Share from the central Data-Cluster NFS-Server for a
windows network over the NFS-Share
/Data/Samba. (Other NFS-Clients each gets its own share eg. /Data/HTTP
for the Web-Server and /Data/ERP for the ERP-Server).
Data-Cluster (2 x DRBD Servers)
NFS Shares Export of DRBD primary device
NFS-Shares Import (/Data/Samba) (Other Servers)
NFS-Server Cluster (/Data/...)
I use the Kernel NFS-Server of the uname -a:
Linux L10-CL2 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 x86_64
x86_64 x86_64 GNU/Linux
The Data-Cluster is a DRBD 1GB IP block device replication system.
If I copy the data files from the present active and functioning Samba
system to the new system, what happens to the file rights from a windows
perspective? Is there anything inside the windows files or bits that has
to do with rights, that can cause read/write right conflicts on the new
system for Windows.
On the new test system, at present I have the problem that I can not
read or write to Windows Office products (MS0) over SMB shares in the
Windows Network on the Samba Server, neither can I read or write with
OpenOffice2 (OO2) products directly on the NFS-Server shares. On the
Samba side in the windows network, a username for 'Workgroup' is asked
where all passwords are rejected (even though the workgroup has been
named as eg. "ABC" in the new Samba server), and I get a read only error
on the NFS side on the NFS-Client. All that prohibit even opening the
files. Only Windows Office product files are effected; strange? All
other files and directories can be created, deleted, edited and moved. I
can also create new office files with OO2, but not edit them afterwards;
the same problem.
I have isolated it to not being able to read or write with MS0 on Samba
shares and OO2 programmes on the NFS-Server directly, only to windows
office files. If I change the *.doc file names to *.txt, I can then edit
them and save them as well; even if the office specific formats are
corrupted, but at least I can edit them then. Otherwise the NFS shares
and the SMB shares behave normally. I have communicated with the NFSv4
group, and there does not seem to be a NFS problem in itself.
Any ideas where to look?
More information about the samba