Bug 8481 - Shadow copy fails on NFSv3 mount with -o lock
Shadow copy fails on NFSv3 mount with -o lock
Status: NEEDINFO
Product: Samba 3.6
Classification: Unclassified
Component: VFS Modules
3.6.0
x64 Linux
: P5 normal
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-23 19:08 UTC by John Koelndorfer
Modified: 2011-10-17 14:06 UTC (History)
0 users

See Also:


Attachments
Log (level 10) from Samba start to attempted shadow copy restore (164.76 KB, application/x-bzip)
2011-09-29 13:44 UTC, John Koelndorfer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Koelndorfer 2011-09-23 19:08:05 UTC
First, relevant tidbits of information:

Operating System: Scientific Linux 6
Kernel version: 2.6.32-131.6.1.el6.x86_64
Windows client: Windows 7 Enterprise x86_64
NFS server: Sun Storage 7310 (runs Solaris, but everything is wrapped up in a pretty web interface; getting a real shell voids your warranty)

Here's how things are set up.  On the Samba 3.6.0 server, homes are mounted by NFSv3 from the Sun Storage 7310 device.  The Sun device uses ZFS, and automatically takes snapshots for us at specified intervals.  We use these snapshots for the purposes of Shadow Copy.

With the default NFSv3 option of -o lock, shadow copy does not work properly.  You can browse files and open them.  If you do this, you can then save the Shadow Copy version anywhere you like (tested with Notepad, not sure how other applications act).

However, using the Previous Versions tab in Windows Explorer, if you attempt to use the "copy" button to copy the file to the same share, it fails:

ERROR: 0x80070021 The process cannot access the file because another process has locked a portion of the file.

You CAN use the copy button to put the file somewhere else, say the local disk.

The restore button fails just like the copy button does with the same error.

Shadow copy works as expected, without the error I have described above, if I mount the NFSv3 volume with -o nolock on the client.  I assume that there is a problem with the way shadow_copy2 is handling file locking.

My share definition:

[homes]
root preexec                = /usr/local/sbin/mkhomedir.sh %U
comment                     = Home Directories
browseable                  = no
writable                    = yes
valid users                 = <redacted>
admin users                 =
create mask                 = 0600
directory mask              = 0700
hide files                  = /desktop.ini/ntuser.ini/NTUSER.*/$RECYCLE.BIN/
wide links                  = yes
vfs objects                 = shadow_copy2
shadow:basedir              = /home/AD
shadow:snapdir              = /home/AD/.zfs/snapshot
shadow:format               = .auto-%s
shadow:fixinodes            = no
shadow:localtime            = yes
Comment 1 Christian Ambach 2011-09-28 14:03:18 UTC
You might need to use fixinodes=yes if ZFS uses the same inode numbers in snapshots than in the live area

     shadow:fixinodes = yes/no

      If you enable shadow:fixinodes then this module will modify the
      apparent inode number of files in the snapshot directories using
      a hash of the files path. This is needed for snapshot systems
      where the snapshots have the same device:inode number as the
      original files (such as happens with GPFS snapshots). If you
      don't set this option then the 'restore' button in the shadow
      copy UI will fail with a sharing violation.
Comment 2 John Koelndorfer 2011-09-28 15:38:17 UTC
(In reply to comment #1)
> You might need to use fixinodes=yes if ZFS uses the same inode numbers in
> snapshots than in the live area
> 
>      shadow:fixinodes = yes/no
> 
>       If you enable shadow:fixinodes then this module will modify the
>       apparent inode number of files in the snapshot directories using
>       a hash of the files path. This is needed for snapshot systems
>       where the snapshots have the same device:inode number as the
>       original files (such as happens with GPFS snapshots). If you
>       don't set this option then the 'restore' button in the shadow
>       copy UI will fail with a sharing violation.

Hi Christian,

Thanks for the reply.  I tested the share with fixinodes = yes and no, and neither fix the issue.

I tested again just now to verify: mounted with -o lock and fixinodes = yes, I get the error I described in the original bug report.

For what it's worth, the snapshot inodes are the same.
Comment 3 Christian Ambach 2011-09-29 13:06:35 UTC
Can you upload a level 10 log so that we can see what is happening?
Comment 4 John Koelndorfer 2011-09-29 13:44:53 UTC
Created attachment 6968 [details]
Log (level 10) from Samba start to attempted shadow copy restore

Christian,

As requested, here is the level 10 log file.  The process for generating this file was as follows:

* Start Samba
* Connect to "homes" as koeln005, which goes to /home/AD/koeln005
* Right click on the file "authorized_keys.txt" > Restore previous versions...
* Selected the only available shadow copy (the folder here should be @GMT-2011.09.29-11.10.00)
* Clicked "Restore".

I got the error message as described in the original bug report.  At this point, I stopped Samba.

There were not any other users on the machine and I started with a clean log to minimize cruft.  Hopefully that helps.  Sadly, the log is still 2.5 MB uncompressed.

Thanks again,

John
Comment 5 Christian Ambach 2011-10-02 09:37:35 UTC
There is a discussion on the samba-technical mailinglist about locking issues when sharing a NFS mount with Samba on newer kernels.

Can you try with

kernel oplocks = no ? Maybe this helps and would point to the NFS client.
strict locking = no might be the second option to try if the first one does not help.
Comment 6 John Koelndorfer 2011-10-17 14:06:56 UTC
(In reply to comment #5)
> There is a discussion on the samba-technical mailinglist about locking issues
> when sharing a NFS mount with Samba on newer kernels.
> 
> Can you try with
> 
> kernel oplocks = no ? Maybe this helps and would point to the NFS client.
> strict locking = no might be the second option to try if the first one does not
> help.

Hi Christian,

Sorry for the delay in replying -- this has been a hectic time for me!

I tried both kernel oplocks = no and strict locking = no (but not both at the same time).

They both seem to fix the issue when NFS locking is enabled.