Hi all, I have been a loyal user of SAMBA since about 1996(?), and I recently upgraded a RH linux based system from by skipping a few generations and going directly from rh9 to FC5. Mostly everything is working, but there is an issue I haven't worked out yet with SAMBA. The main server here in our group has several shares, including some that are mounted from other servers via nfs, which meant an upgrade from samba 2.2.12 to 3.0.23c-1.fc5. The older server had no problem re-exporting the NFS mounted shares as SMB shares, but it won't work on the new server. Users are able to mount the share from winxp/win2k clients, but cannot create or edit any new files. Non-nfs mounted shares work fine, and the nfs mounts can be readily accessed R/W from the unix server itself. The symptoms are multiple. In some instances, clients get a disk full message, while in others they get a windows dialog box with the title bar showing "Error coping File or Folder" and the message " Cannot copy accounts: The process cannot access the file because another process has locked a portion of the file". If I set the debug level to 1 (for now), I get the following messages: [2007/01/02 18:39:10, 3] smbd/oplock_linux.c:linux_set_kernel_oplock(162) linux_set_kernel_oplock: Refused oplock on file this.file, fd = 26, dev = 15, inode12620340. (Resource temporarily unavailable) [2007/01/02 18:39:10, 10] locking/brlock.c:brl_locktest(1066) brl_locktest: posix start=0 len=12785 locked for fnum 10883 file this.file [2007/01/02 18:39:10, 10] locking/locking.c:is_locked(134) is_locked: flavour = WINDOWS_LOCK brl start=0 len=12785 locked for fnum 10883 file this.file [2007/01/02 18:39:10, 3] smbd/error.c:error_packet(146) error packet at smbd/reply.c(3098) cmd=47 (SMBwriteX) NT_STATUS_FILE_LOCK_CONFLICT Now what's interesting is that I can create a new file on the share from windows explorers, with the usual right click, new (folder, text file, etc), and I can delete files, but I cannot edit any or "drag" any files into the share. FWIW this is with nfs v3 client and server, and this is probably off-topic, but a nfsstat on the original NFS server machine, gives the following: # nfsstat Server rpc stats: calls badcalls badauth badclnt xdrcall 491445 9 3 6 0 I'll have to explore this, but as far as I can tell this really seems to be a NFS-SMB interoperability issue. Does anyone have any idea how to resolve this? Cheers, Jim
On Tue, Jan 02, 2007 at 07:39:51PM -0800, Jim McInerny wrote:> I have been a loyal user of SAMBA since about 1996(?), and I recently > upgraded a RH linux based system from by skipping a few generations > and going directly from rh9 to FC5. Mostly everything is working, > but there is an issue I haven't worked out yet with SAMBA.As an emergency measure you might try 'posix locking = no' and 'kernel oplocks = no'. This will however destroy coherence with unix processes and other NFS clients. Re-exporting NFS mounts is not a good idea, why don't you put Samba on the NFS server? Volker
Volker Lendecke wrote:> On Tue, Jan 02, 2007 at 07:39:51PM -0800, Jim McInerny wrote: > >/ I have been a loyal user of SAMBA since about 1996(?), and I recently/> >/ upgraded a RH linux based system from by skipping a few generations /> >/ and going directly from rh9 to FC5. Mostly everything is working, / > >/ but there is an issue I haven't worked out yet with SAMBA./ > > As an emergency measure you might try 'posix locking = no' > and 'kernel oplocks = no'. This will however destroy > coherence with unix processes and other NFS clients. > > Re-exporting NFS mounts is not a good idea, why don't you > put Samba on the NFS server?I try to avoid re-exporting NFS mounts! And yes, I also prefer few (!) big file servers ... But this is common practice: Very few of our user know, where one of the 100 (logical) disks reside. They use one of the few samba servers and follow symbolic links (to auto mounted nfs disks). And I prefer to be able to move disk space, without the user knowing essentially, where the disks are really installed. So, oplocks with samba and nfs should work reasonably. Rupert
On Thu, Mar 22, 2007 at 11:48:32AM +0100, Rupert Kolb wrote:> But this is common practice: > Very few of our user know, where one of the 100 (logical) disks reside. > They use one of the few samba servers and follow symbolic links (to auto > mounted nfs disks). > And I prefer to be able to move disk space, without the user knowing > essentially, where the disks are really installed. > > So, oplocks with samba and nfs should work reasonably.As an alternative approach you might want to look at MSDFS with which you can achieve pretty much the same appearance to your users. Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/20070322/f84a8469/attachment.bin