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
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.
(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.
Can you upload a level 10 log so that we can see what is happening?
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
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.
(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.
closing as the problem is obviously not Samba but the NFS client implementation. People should really stop trying to reexport NFS volumes.