I've a weird problem with Samba. I'm using Samba to share a filesystem between two linux systems because I believe I need byte range locking to prevent multiple processes on different computers from reading/writing the same ISAM records. I have a Debian wheezy file server running Samba; no domain controller, just a simple, single share. I have a debian wheezy KVM mounting a share via CIFS, forcing UID and GID; UID/GID are the same on the two systems. I use a credentials file with non-root user and password. I disabled oplocks and client caching. The shared dir has ug+rw for all files, and has ug+x for all dirs; the same non-root user and group owns all files and dirs. I've even gone so far as to add ug+s on all dirs, to no avail. General access seems to be OK. But there's a failure in one specific instance. On the KVM, I'm running unibasic (business basic). I wrote a program to test record locking when reading indexed ISAM files. Running it on two KVMs, I verified that record locking does work; the lock passed between the two programs very nicely. But I encountered a problem when creating indexed ISAM files. When a UB program builds an indexed ISAM DB, it creates both a data file and an index file on the file server. The problem is that it *always* fails when a non-root user runs unibasic (it can't create the index structure within the index file). But it succeeds when running the program as root. Oddly, if I leave ug+s off the dirs on the server, root:root will own one of the files in the pair (regardless of forceuid/forcegid on the client mount). This is perplexing. The CIFS client mount generally works. But for this particular case, it always fails. The program does work correctly if I run it on the file server. Where do I start looking to get to the root of the problem? In Debian's samba 3.6.6? In Debian's CIFS module for linux 3.2? I can save a tcpdump of the packet exchanges in each case; but I've no idea how to decipher the packet contents. Is it possibly related to how unibasic names the files? It uses a single name, say "myisam". The file containing the data records is named in lower case (myisam); the file containing the c-tree index(es) is named in upper case (MYISAM). I specified 'case sensitive = yes' in smb.conf and did not specify 'nocase' in the CIFS mount. Is it possible CIFS or Samba (or both) are inadvertently performing a case insensitive compare? Or otherwise not differentiating between the two? Thanks!
On Wed, Feb 27, 2013 at 04:00:23PM -0500, Neal Murphy wrote:> I've a weird problem with Samba. I'm using Samba to share a filesystem between > two linux systems because I believe I need byte range locking to prevent > multiple processes on different computers from reading/writing the same ISAM > records. > > I have a Debian wheezy file server running Samba; no domain controller, just a > simple, single share. I have a debian wheezy KVM mounting a share via CIFS, > forcing UID and GID; UID/GID are the same on the two systems. I use a > credentials file with non-root user and password. I disabled oplocks and > client caching. The shared dir has ug+rw for all files, and has ug+x for all > dirs; the same non-root user and group owns all files and dirs. I've even gone > so far as to add ug+s on all dirs, to no avail. General access seems to be OK. > But there's a failure in one specific instance. > > On the KVM, I'm running unibasic (business basic). I wrote a program to test > record locking when reading indexed ISAM files. Running it on two KVMs, I > verified that record locking does work; the lock passed between the two > programs very nicely. But I encountered a problem when creating indexed ISAM > files. > > When a UB program builds an indexed ISAM DB, it creates both a data file and > an index file on the file server. The problem is that it *always* fails when a > non-root user runs unibasic (it can't create the index structure within the > index file). But it succeeds when running the program as root. Oddly, if I > leave ug+s off the dirs on the server, root:root will own one of the files in > the pair (regardless of forceuid/forcegid on the client mount).How exactly does it fail ? This will help determine the problem.