https://forums.qrecall.com/posts/list/6.page JForum - http://www.jforum.net
What's my best course forward at this point? I assume that the archive is as big as it is because it now contains both unencrypted and encrypted data. Would merging layers or compacting the archive clean it out to the point that I could continue the encryption?

Ralph]]> https://forums.qrecall.com/posts/preList/619/2917.page https://forums.qrecall.com/posts/preList/619/2917.page GMT
Ralph,

Thanks for sending a diagnostic report. From the logs, I can see that your encryption action is failing because the macOS encryption services are crashing. Some systems?and I don't yet have a sense for which ones?have a great deal of difficulty executing multiple encryption/description operations simultaneously. Sometimes the operations fail (which QRecall can deal with), but for some users the operations crash.

So what's happening is that your encryption action is crashing. For safety, Qrecall first makes an encrypted copy of the archive data. So if there is a problem, you won't be left with a half-encrypted archive. That intermediate copy is what's using up your disk space.

First, let's fix the disk space problem

[list]Control/Right+click the archive in the Finder and choose Show Package Contents[/list]
[list]Trash any files that begin with the name [b]repository_scribble[/b][/list]
[list]Close the window and empty the trash[/list]
Now you should be able to start a new encryption task. But to keep that from crashing again, you'll want to limit the number of concurrent encryption operations QRecall will perform.

[list]Make sure you've upgraded to QRecall 2.0.7[/list]
[list]Go to QRecall > Preferences > Advanced[/list]
[list]Find the [i]Concurrent Encryption Limit[/i] setting and set it to 1 or 2[/list]
Now try the encrypt command again.

You can try adjusting the concurrent limit to a higher value, just realize that if it's too high some QRecall actions will randomly crash. One of the best ways to test a higher setting is using a verify command; verify performs a lot of concurrent encryption operations and there won't be any data loss if it crashes.]]> https://forums.qrecall.com/posts/preList/619/2918.page https://forums.qrecall.com/posts/preList/619/2918.page GMT https://forums.qrecall.com/posts/preList/619/2919.page https://forums.qrecall.com/posts/preList/619/2919.page GMT https://forums.qrecall.com/posts/preList/619/2920.page https://forums.qrecall.com/posts/preList/619/2920.page GMT
Apparently this is a result of the way router presents the file to Qrecall. The disk shared through the router doesn't show up as a device is Finder, but is accessed through [i]Go/Connect to Finder[/i] where it shows up as an smb:// connection to my ISP's router. That connection shows up in Finder as a Volume, listing the contents of the drive. I can open most of the files listed, but not the archive.

Is there a way to connect to this router that will work with qrecall, or do I just have to go back to my previous setup of mounting the archive directly on my iMac? The router, if I can make it work, will give me a USB3 connection instead of the USB2 connection the iMac provides, and hopefully be more reliable than my previous router connection has been.]]> https://forums.qrecall.com/posts/preList/619/2921.page https://forums.qrecall.com/posts/preList/619/2921.page GMT
I don't think that the problem is [i]how[/i] the volume is mounted. Basically, QRecall (and most software) doesn't care how the volume appears in the Finder or what its mountpoint is. Software (QRecall) gets a path to the document, and it uses that path to manipulate the files. The rest is unimportant details (to the software).

I suspect you have a permissions problem or your SMB server doesn't support the necessary file locking features.

QRecall is getting stuck trying to obtain exclusive access to the archive. It uses several techniques to do this, because not all filesystem support the same file locking features. In your case, it's getting stuck trying to obtain a "distributed lock". The exact mechanics of a distributed lock vary from one filesystem to the next, but most involve create a "lock" file used to coordinate access from multiple clients. This what I found in your log:

[code]2016-12-17 21:32:43.883 breaking distLock after 150 tries
2016-12-17 21:33:51.114 breaking distLock after 150 tries
2016-12-17 21:35:00.437 breaking distLock after 150 tries
2016-12-17 21:36:11.570 breaking distLock after 150 tries[/code]
This should never happen, and if it does it should only happen once; once a stale distLock is broken, it should start working again immediately, but clearly this one still isn't.

When a distributed lock is implemented as a file, it must have read and write access to that directory. You can test this in the Terminal. With the archive mounted on your SMB volume, issue these commands:

[code]user$ cd <Drag and drop your archive icon here>
user$ touch .semaphore
user$ rm .semaphore[/code]
The .semaphore file is the filesystem object used to coordinate the lock. If you can modify it and delete it as a user, then it should work. If any of these commands report errors, then I suspect you have a permissions or access issue. QRecall documents are just like any other file; your user account must have read, write, and search permission on the contents of the archive package in order to update it.

Now if these commands all work just fine, and the rest of the archive package has the correct ownership and permissions, then I'm stumped. I would suspect that something about the file locking features implemented by your SMB server doesn't line up with what macOS is expecting.]]> https://forums.qrecall.com/posts/preList/619/2923.page https://forums.qrecall.com/posts/preList/619/2923.page GMT
[cpe-172-248-32-105:~] ralph% cd /Volumes/volume2
[cpe-172-248-32-105:/Volumes/volume2] ralph% touch .semaphore
[cpe-172-248-32-105:/Volumes/volume2] ralph% rm .semaphore
[cpe-172-248-32-105:/Volumes/volume2] ralph%

The permissions for both the archive and the volume containing it show up in Finder as "custom access," and in terminal as

[cpe-172-248-32-105:/volumes/volume2] ralph% ls -l
total 4160
drwx------ 1 ralph staff 16384 Dec 18 03:10 3rd backup.quanta

but I don't understand Unix permissions well enough to know If that's something I should try to change that or not. I also notice that I'm apparently running a shell provided by the router, rather than one from my computer. When I run terminal with the router disconnected I get "[Ralphs-rMBP:~] ralph%" and as soon as I connect to the router it changes to the one above.

Maybe it's time for me to take this to the router's support group. Is there anything else I should tell them about the problem that might help solve it from their end?



]]> https://forums.qrecall.com/posts/preList/619/2925.page https://forums.qrecall.com/posts/preList/619/2925.page GMT
Close (but no cigar)

You need to test the access to the directory [i]inside[/i] the archive package. Try these commands:

[code]cd '/Volumes/volume2/3rd backup.quanta'
touch .semaphore
rm .semaphore[/code]

However, since it appears that the archive belongs to you, and I assume that you're performing the capture from the same computer using your account, it should work. Which might mean we're back to square one.]]> https://forums.qrecall.com/posts/preList/619/2926.page https://forums.qrecall.com/posts/preList/619/2926.page GMT
[cpe-172-248-32-105:/Volumes/volume2] ralph% cd '/Volumes/volume2/3rd backup.quanta'
[cpe-172-248-32-105:/Volumes/volume2/3rd backup.quanta] ralph% touch .semaphore touch: .semaphore: Permission denied
[cpe-172-248-32-105:/Volumes/volume2/3rd backup.quanta] ralph% rm .semaphore
rm: .semaphore: No such file or directory

Is changing that permission something I can do in a way that will stick, or do I need to ask the router people for a change? And if so, what specifically should I ask them for?]]> https://forums.qrecall.com/posts/preList/619/2927.page https://forums.qrecall.com/posts/preList/619/2927.page GMT Then that's the problem. From the perspective of the router's file server, you do not have permission to modify files inside the archive package directory. This pretty much rules out capturing data to it.

Soooooo

If you are the only computer & users capturing to this archive, then there might be a simple solution. Let's try this:

[code]chown -R $(id -u) '/Volumes/volume2/3rd backup.quanta'[/code]
This will change ownership of the archive package directory, and all of the files it contains, to the user account you are currently logged in as. After that, try to accessing/capturing to the archive.

Again, if you're the only user/system accessing this archive that might fix the problem. If you share this archive with other users, then that complicates things a bit.]]> https://forums.qrecall.com/posts/preList/619/2928.page https://forums.qrecall.com/posts/preList/619/2928.page GMT
The router apparently does not support MacOS file versions, because when I edit a text file in TextEdit and save it, I get an error message that says:

[b]The document ?focusing_your_touch1.txt? is on a volume that does not support permanent version storage.
You will not be able to access older versions of this document once you close it.[/b]

The file does save, though.

I'll give TP-link support a try and see if they have any ideas. Is there anything in particular that it might be useful to tell them about the archive?

Ralph]]> https://forums.qrecall.com/posts/preList/619/2929.page https://forums.qrecall.com/posts/preList/619/2929.page GMT
Version support is a red herring. This is only supported on macOS formatted volumes because it's a really complex feature. But it won't interfere with QRecall. QRecall tries to use only the very basic filesystem features so it can be compatible with a wide range of filesystems, servers, and volumes formats. When it does use a fancy filesystem features (like file range locking or atomic swaps), it implements fallback methods to accomplish the same thing when it finds itself using a filesystems that don't support them.

I'll assert that your problems are entirely ones of ownership and permissions, so here's the short course.

On a volume the honors ownership and permissions, you can access the files you own or have been granted access to by its owner. (There's a lot of exceptions and caveats to that rule, but this is the simple explanation.) When you create a file, you own it by default.

So Amy creates a file, but Bob can't read or write it because Amy didn't grant Bob access. This is the default/typical file ownership rule at work, and what keeps users of your "Guest" account from reading your email. The same rule applies to QRecall archives.

So Amy creates an archive, but Bob can't modify it.

Now if both Amy and Bob need to capture to the same archive, it's typically because the archive is on an external drive or a shared volume. An external drive is easy to fix by setting the drive to "Ignore ownership and permissions" on both systems. Now both computers can freely access the archive modified by the other.

On shared volumes things get a little more complicated. If both Amy and Bob both have their own accounts on the server, they have the same problem as before; Amy's archive will belong to Amy. Permissions, however, are managed by the server and there will be no option to ignore them.

The simplest solution is for Bob to sign onto the server as Amy, vice versa, or create a neutral account (Pat) that both users can connect to the server. When connected to a file server, the files you create belong to the account you authenticated as, not your user account. This is easy to forget as most people use the same account name on the server as they do on their computer. The complication here is if both Amy and Bob need to connect to the server using their account for other purposes. Most file servers either do not support, or make it difficult to, open multiple connections to the same server using different accounts.

Another possible solution is to change the umask of your account. The umask adjusts the default permissions granted to new files. You can set it up so that other users in your group (or everyone) can share files you create by default. Unfortunately, this is a global setting that also affects the files you create locally on your hard drive, so it might not be what you want and has obvious security implications.

If you're only using your router/server for QRecall backups, the most manageable solution is to have all clients connect to the server using the same account. (You'll wan to save that account name and password in your keychain too.) Now change the ownership of the archive to the account you all share, and you should have trouble-free access to that archive from all of your systems. How you accomplish that with your particular NAS/Server is an exercise left to the reader.
]]> https://forums.qrecall.com/posts/preList/619/2930.page https://forums.qrecall.com/posts/preList/619/2930.page GMT
At this point my best solution may be to return my new router and go back to my old system, so my only questions now are where the 204gb backup went and if the fact that it doesn't show as completed in the log is anything I should worry about?

When you look at my report you'll find a number of failed "waiting for archive" backup attempts. I caused those by trying to run a "backup to router" action while the drive was mounted on my computer, and not realizing why it wasn't going through.]]> https://forums.qrecall.com/posts/preList/619/2931.page https://forums.qrecall.com/posts/preList/619/2931.page GMT <clip>
The drive being backed up contains 360GB and the archive now shows in Finder as 713GB. This is about what it was before the backup, so I'm not sure where the new layer went. It's somewhere, though, because I can see it when I open the archive, and can restore files from it, (I should have been making notes during this process, but wasn't.) The new layer contains files that haven't changed in years, so I don't know what criteria Qrecall was using for changed files.[/quote]
What's happening is QRecall is recapturing every file on your hard drive because the identity key is different. An archive is organized by owners (define by identity keys), which contain volumes, which contain files and folders. If your identity key changes QRecall treats your files as if they were from a completely different computer and recaptures them all. These new files will be contained within the new owner and volume at the root of the archive.

Use the browser bar at the bottom to navigate to the root of the archive to see the new owner and volumes. Use the Combine Items command to stitch two owners, or two volumes, that are actually the same into a single history.

Alternatively, you can reinstall the original identity key and QRecall will resume updating the history you already have. If you're wondering which key you have installed, go to QRecall > Preferences > Identity key, hold down the Option key while clicking on the Enter Key button. In the "key" field, you'll see a light grey number. That is your key's serial number. Now use this [url=https://secure.qrecall.com/account.jsp?showSerialNos=true]Magic Account URL[/url] on the QRecall website, and it will list the serial number of each of your identity keys.

The reason the archive isn't (much) bigger is because it's all duplicate data. (Duplicates of that "other" computer's files already in the archive.)

[quote]The Qrecall log did not record the completion of that backup.[/quote]
That's because the capture isn't finishing. The capture action is crashing trying to encrypt data. Try setting your Concurrent Encryption Limit setting to 1 and run the capture again. Meanwhile, I'll fire off another blistering bug report to Apple.

[quote]At this point my best solution may be to return my new router and go back to my old system, so my only questions now are where the 204gb backup went and if the fact that it doesn't show as completed in the log is anything I should worry about?[/quote]
Well, we should be worried about the encryption framework crashing on you. That's not productive at all.

If you didn't mean to change identity keys, that's something that you should look into. Aside from the annoyance of recapturing your entire hard drive and having separate history, or taking the trouble to combine them, it doesn't bother QRecall?but it might bother you.

Honestly, I would hope that you can get this working on your router. If it's possible for all of the QRecall clients to connect to the router with the same authentication, they should be able to peacefully share the single archive.]]> https://forums.qrecall.com/posts/preList/619/2932.page https://forums.qrecall.com/posts/preList/619/2932.page GMT
I originally purchased two identity keys to use one for each computer, but didn't keep track of which was which. As some point in my wrestling with the new router, Qrecall said I didn't have an identity key and needed to reinstall one. I picked the wrong one so ended up with the same key on both machines. I think I've that sorted out now, and am back to one key per computer. I assume I can just delete the extra layer that I created unintentionally without affecting the rest of the backup

[quote]The capture action is crashing trying to encrypt data. Try setting your Concurrent Encryption Limit setting to 1 and run the capture again. Meanwhile, I'll fire off another blistering bug report to Apple.
[/quote]

I had set the Current Encryption Limit to 2 after you suggested 1 or 2, but I'll take it down to 1 now.

[quote]Honestly, I would hope that you can get this working on your router. If it's possible for all of the QRecall clients to connect to the router with the same authentication, they should be able to peacefully share the single archive.[/quote]

I'm backing up two computers to the same archive, a MBP and an iMac. I'm the sole user of the MBP and back it up from my account. My wife is the primary user of the iMac and I've been running that backup from her account. I seldom even log onto the iMac, but it looks like Qrecall could run scheduled backups of the whole iMac from my account without my being logged in. Is that correct, and should that satisfy the router's desire for a single common user? (I'm uid 501 on both machines.)

One final item -- my archive now won't open from my wife's account on the iMac, even though it opens fine in my iMac account and on my MBP.

I'm off to a week in the desert tomorrow or Sunday, so may not get back to this till next year. Thanks again for all the hand-holding you provide. I really appreciate it.

Ralph]]> https://forums.qrecall.com/posts/preList/619/2933.page https://forums.qrecall.com/posts/preList/619/2933.page GMT A more surgical approach would be to find the "new" volume in the other owner and simply delete that from the archive. That way, you don't have to delete any subsequent layers.

[quote]I had set the Current Encryption Limit to 2 after you suggested 1 or 2, but I'll take it down to 1 now.[/quote]
Let me know how that goes, or just send another diagnostic report when you get back.

[quote]I seldom even log onto the iMac, but it looks like Qrecall could run scheduled backups of the whole iMac from my account without my being logged in. Is that correct, and should that satisfy the router's desire for a single common user? (I'm uid 501 on both machines.)[/quote]
Here's the important concept:

[b][i]The account on your computer is independent of the account you use on the file server.[/i][/b]

This is the concept that is most confusing when working with networked volumes. It does NOT matter what your user account is. The files written to your file server will belong to the (server) account you use to authenticate with when you connect to the server.

If you and your wife can get set up so that both of your local accounts connect to the file server using the same server account, then the files (archives) on the shared volume will belong to both of you, and it doesn't matter what your local account is or what UID you're using.

The reason I'm short on practical advice is that different file servers, NAS devices, and so on handle this differently. For example, Apple's Airport Time Capsule has (basically) two different authentication modes for its shared disk: shared and per-account. The "shared" modes allow all network users to access the files on the Time Capsule as if they were all the same user. This is the effect you need, and this is the mode I use with my Time Capsules. All QRecall users can connect to the Time Capsule and use the same archives, since (from the Time Capsule's perspective) they are all the same user. If I switched my Time Capsule to the per-account mode, I'd have the same problem you're experiencing.

Other devices handle accounts and ownership differently. Some server/NAS devices, for example, deliberately extend file ownership to the shared volume using your local account ID, effectively emulating an external drive. So YMMV and you'll need to find the magic combination that works for you.]]> https://forums.qrecall.com/posts/preList/619/2934.page https://forums.qrecall.com/posts/preList/619/2934.page GMT
Ralph]]> https://forums.qrecall.com/posts/preList/619/2938.page https://forums.qrecall.com/posts/preList/619/2938.page GMT
Looking at the logs, QRecall is still stuck trying to obtain (and later break) the shared file semaphore. I suspect a permissions problem, but it's hard to tell from the logs.

I'd be very much interested in knowing the ownership and permissions of all of the files in both the archive that is stuck and the one that is working. If you have the time, open an Terminal window and issue this 'ls' command for each archive:
[code]ls -lna@e /Volumes/Backup/PathToArchive.quanta[/code]
email the results, or post them here.]]> https://forums.qrecall.com/posts/preList/619/2940.page https://forums.qrecall.com/posts/preList/619/2940.page GMT
The first listing is from a folder containing only the archive, 3rd which I had moved to a separate folder because it felt like the router would be easier to configure if the shared file was in a separate folder than if it was at the top level.

The second listing is from the volume containing my test archive, named testbackup.quanta. When I saw the hidden files that this directory contained I thought maybe that was the problem -- that when I moved 3rdbackup.quanta into a separate folder I had not move some invisible file that it needed in order to open. So I moved it back to the top level of that volume.

That didn't solve the problem. testbackup.quanta will open properly, but 3rdbackup.quanta hang with the "file in use" message.


[b]First listing: 3rd backup.quanta in a separate folder/volume2/backup[/b]
[code][cpe-172-248-32-101:~] ralph% ls -lna@e /Volumes/volume2/backup
total 176
drwx------ 1 501 20 16384 Jan 15 17:26 .
drwx------ 1 501 20 16384 Jan 15 19:19 ..
-rwx------ 1 501 20 6148 Jan 15 09:16 .DS_Store
-rwx------ 1 501 20 4096 Jan 15 17:26 ._Attribute.rtf
drwx------ 1 501 20 16384 Jan 15 09:15 3rd backup.quanta
-rwx------@ 1 501 20 24585 Oct 26 2015 Attribute.rtf
com.apple.FinderInfo 32 [/code]

[b]2nd listing: directory containing testbackup.quanta at top level[/b]

[code] com.apple.FinderInfo 32
0: ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C deny add_file,add_subdirectory,directory_inherit,only_inherit
-rwx------ 1 501 20 8196 Jan 16 2017 .DS_Store
drwx------ 1 501 20 16384 Nov 29 03:29 .Spotlight-V100
-rwx------ 1 501 20 4096 Nov 28 20:48 ._testbackup Backup Encryption Key.plist
-rwx------ 1 501 20 4096 Nov 28 20:48 ._testbackup Recovery Passphrase.txt
-rwx------ 1 501 20 4096 Jan 15 19:15 ._testbackup Recovery modified.txt
-rwx------ 1 501 20 4096 Nov 28 19:40 ._testbackup.quanta
drwx------ 1 501 20 16384 Jan 16 2017 .fseventsd
-rwx------ 1 501 20 16777216 Nov 29 03:29 .journal
-rwx------ 1 501 20 4096 Nov 29 03:29 .journal_info_block
-rwx------@ 1 501 20 2028 Nov 28 20:46 testbackup Backup Encryption Key.plist
com.apple.metadata:_kMDItemUserTags 42
-rwx------@ 1 501 20 16 Nov 28 20:48 testbackup Recovery Passphrase.txt
com.apple.TextEncoding 15
com.apple.metadata:_kMDItemUserTags 42
-rwx------@ 1 501 20 75 Jan 15 19:15 testbackup Recovery modified.txt
com.apple.TextEncoding 15
com.apple.metadata:_kMDItemUserTags 42
com.apple.metadata:kMDLabel_ag4ow3qfx44prohk42bi6mok64 89
drwx------@ 1 501 20 16384 Jan 15 19:41 testbackup.quanta
com.apple.FinderInfo 32
com.apple.metadata:_kMDItemUserTags 42
[cpe-172-248-32-101:~] ralph% [/code]

[b]third listing Directory containing 3rdbackup.quanta returned to top level in /volume2[/b]
[code][cpe-172-248-32-101:~] ralph% ls -lna@e /Volumes/volume2
total 329984
drwx------ 1 501 20 16384 Jan 16 2017 .
drwxr-xr-x@ 7 0 0 238 Jan 15 22:04 ..
com.apple.FinderInfo 32
0: ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C deny add_file,add_subdirectory,directory_inherit,only_inherit
-rwx------ 1 501 20 10244 Jan 16 2017 .DS_Store
drwx------ 1 501 20 16384 Dec 16 16:19 .Spotlight-V100
drwx------ 1 501 20 16384 Dec 22 17:25 .TemporaryItems
drwx------ 1 501 20 16384 Dec 22 00:04 .Trashes
-rwx------ 1 501 20 4096 Jan 15 17:26 ._Attribute.rtf
-rwx------ 1 501 20 4096 Dec 19 21:41 ._focusing_your_touch1.txt
-rwx------ 1 501 20 4096 Jan 15 19:19 ._focusing_your_touchxxx.txt
-rwx------ 1 501 20 0 Dec 21 02:23 .com.apple.timemachine.donotpresent
drwx------ 1 501 20 16384 Jan 16 2017 .fseventsd
-rwx------ 1 501 20 159383552 Dec 16 16:19 .journal
-rwx------ 1 501 20 4096 Dec 16 16:19 .journal_info_block
drwx------ 1 501 20 16384 Jan 16 2017 3rd backup.quanta
-rwx------@ 1 501 20 24585 Oct 26 2015 Attribute.rtf
com.apple.FinderInfo 32
-rwx------ 1 501 20 79372 Dec 6 01:16 Your request has been received - Powered by TP-LINK.pdf
drwx------ 1 501 20 16384 Jan 16 2017 backup
-rwx------@ 1 501 20 1520 Dec 19 21:41 focusing_your_touch1.txt
com.apple.TextEncoding 15
com.apple.metadata:kMDLabel_ag4ow3qfx44prohk42bi6mok64 121
-rwx------@ 1 501 20 1572 Jan 15 19:19 focusing_your_touchxxx.txt
com.apple.TextEncoding 15
com.apple.metadata:_kMDItemUserTags 42
com.apple.metadata:kMDLabel_ag4ow3qfx44prohk42bi6mok64 169
drwx------ 1 501 20 16384 Jun 26 2015 xtra 2
[cpe-172-248-32-101:~] ralph% [/code]]]> https://forums.qrecall.com/posts/preList/619/2941.page https://forums.qrecall.com/posts/preList/619/2941.page GMT
Thanks for the info, but it wasn't quite what I was looking for. I'm interested in seeing the [i]insides[/i] of the archive packages. These commands should do the trick:
[code]ls -lna@e '/Volumes/volume2/testbackup.quanta'
ls -lna@e '/Volumes/volume2/3rd backup.quanta'[/code]
I'm interested in the ownership, permissions, and existence of the various [b].lock[/b] and [b].share[/b] semaphore files inside the archive package.]]> https://forums.qrecall.com/posts/preList/619/2943.page https://forums.qrecall.com/posts/preList/619/2943.page GMT
[code][cpe-172-248-32-101:~] ralph% ls -lna@e '/Volumes/volume2/3rd backup.quanta'
total 1392904600
drwx------ 1 501 20 16384 Jan 16 05:58 .
drwx------ 1 501 20 16384 Jan 16 05:57 ..
-rwx------ 1 501 20 1326888 Jan 15 09:15 displayname.index
-rwx------ 1 501 20 90732048 Jan 15 09:15 filename.index
-rwx------ 1 501 20 508872 Jan 15 09:15 fill.index
-rwx------ 1 501 20 3221225528 Jan 15 09:15 hash.index
-rwx------ 1 501 20 15137230 Jan 15 09:15 hash_adjunct.index
-rwx------ 1 501 20 10650776 Jan 15 09:14 layer.index
-rwx------ 1 501 20 16777220 Jan 15 09:15 negative.index
-rwx------ 1 501 20 1017 Jan 15 09:14 outline.index
-rwx------ 1 501 20 213098544 Jan 15 09:15 package.index
-rwx------ 1 501 20 213100 Jan 15 09:15 package_adjunct.index
-rwx------ 1 501 20 709597389288 Jan 15 09:15 repository.data
-rwx------ 1 501 20 1237 Dec 15 04:32 security.plist
-rwx------ 1 501 20 122 Jan 15 09:15 sequence.index
-rwx------ 1 501 20 5771 Aug 12 04:50 settings.plist
-rwx------ 1 501 20 836 Jan 15 09:15 status.plist
-rwx------ 1 501 20 4340 Jan 16 05:58 view.plist[/code]

[code][cpe-172-248-32-101:~] ralph% ls -lna@e '/Volumes/volume10/testbackup.quanta'
total 1139056
drwx------@ 1 501 20 16384 Jan 15 22:31 .
com.apple.FinderInfo 32
com.apple.metadata:_kMDItemUserTags 42
drwx------ 1 501 20 16384 Jan 15 19:15 ..
-rwx------ 1 501 20 9744 Nov 28 19:50 displayname.index
-rwx------ 1 501 20 198024 Nov 28 19:50 filename.index
-rwx------ 1 501 20 56 Jan 15 19:38 fill.index
-rwx------ 1 501 20 12344 Nov 28 19:50 hash.index
-rwx------ 1 501 20 310197 Nov 28 19:50 hash_adjunct.index
-rwx------ 1 501 20 4296 Nov 28 19:50 layer.index
-rwx------ 1 501 20 904 Nov 28 19:50 outline.index
-rwx------ 1 501 20 48 Jan 15 19:38 package.index
-rwx------ 1 501 20 311452 Jan 15 19:38 package_adjunct.index
-rwx------ 1 501 20 582265112 Jan 15 19:40 repository.data
-rwx------ 1 501 20 1237 Jan 15 19:40 security.plist
-rwx------ 1 501 20 122 Jan 15 19:40 sequence.index
-rwx------ 1 501 20 819 Nov 28 19:51 status.plist
-rwx------ 1 501 20 4734 Jan 15 22:31 view.plist[/code]]]> https://forums.qrecall.com/posts/preList/619/2945.page https://forums.qrecall.com/posts/preList/619/2945.page GMT
I don't see any differences in the ownership or permissions for the two archives, and I don't see any stale .lock or .share files that might be blocking access to it.

So, the only thing I can think of at this point is that the file server supports file locking and/or advisory locks and is holding an orphaned lock on one of the files in 3rd backup.quanta. This can happen when a network clients obtains a lock on a file and then gets disconnected from the server.

This can usually be solved by restarting the server. If this is a network device that runs 24/7, it's easy for orphaned locks to stay around for weeks. (Note that in cases like this, restarting the clients won't have any effect on the problem.)

If that doesn't work, you can try repairing the 3rd backup archive (presuming you have enough free space), choosing the "Copy recovered content to new archive" option (say 4th backup archive). QRecall will extract all of the data in the original archive and use it to create a brand new one. When finished, you can discard the old archive.]]> https://forums.qrecall.com/posts/preList/619/2947.page https://forums.qrecall.com/posts/preList/619/2947.page GMT