Ignite Global Support Home Start a conversation Sign in
Start a conversation
  1. Northplains Xinet Support
  2. Articles
  3. Public Articles

macOS Quick Look over AFP Leaves Files Marked “Open/In Use” in Xinet

Contents

Overview

When image files are previewed using macOS Quick Look from an AFP-mounted volume, they may continue to appear as “open/in use” in Xinet even after closing the preview—often clearing only after the AFP volume is unmounted/disconnected.

In the reported environment (Xinet 2026.02.27 with macOS 15.7.4 clients), this was determined to be macOS Quick Look/Finder behavior over AFP (client-side handle/lock persistence), not a Xinet/ksd server defect.

Solution (Mitigation)

Issue

Files (primarily image assets such as TIFFs) opened and closed using macOS Quick Look from an AFP share continue to show as open/in use in Xinet until the AFP volume is disconnected/unmounted.

Common Indicators

  • Xinet admin/open-file views show the asset as open when no user appears to be actively editing it.
  • Creative applications may display a conflict message such as: “file is already open by another user or application.”

Affected Environment (as reported)

  • Xinet Server: 2026.02.27
  • Client: macOS 15.7.4
  • Protocol: AFP (Apple Filing Protocol)

Cause

This behavior is consistent with macOS Quick Look/Finder preview behavior over AFP, where the client can keep AFP file handles open longer than expected. Because the file handle remains open at the AFP session level, the server continues to treat the file as “in use” until the AFP session disconnects (for example, when the volume is unmounted).

A key validation in this case was reproducing the same behavior against a non-Xinet AFP server implementation (e.g., Netatalk) and confirming server-side open AFP file descriptors persisted after Quick Look preview (e.g., via lsof). This supports the conclusion that the issue is not specific to Xinet/ksd.

Mitigation Option 1: Reduce Finder/Quick Look Preview Locking (Workaround)

Adjust Finder settings to limit previews/thumbnails that can trigger or prolong file engagement over AFP:

  1. In Finder, open the folder view used to browse the AFP-mounted assets.
  2. Go to View → select Hide Preview.
  3. Go to View → Show View Options, then disable preview-related options such as:
    • Show icon preview (and any similar thumbnail/icon preview settings available in your macOS version)
  4. Re-test the workflow:
    • Preview an image with Quick Look
    • Close Quick Look
    • Confirm whether the file stops appearing as “open/in use” sooner than before

Note: This mitigation reduces the likelihood/impact but may not fully eliminate AFP-client locking edge cases in all macOS versions.

Mitigation Option 2 (Recommended Long-Term): Move Away from AFP for Mac Workflows

If the workflow depends on Quick Look and modern macOS clients, plan to transition file access away from AFP (for example, to SMB) to reduce protocol/client compatibility issues that can manifest as lingering locks/open handles.

How to Validate You’re Seeing the Same Behavior

  1. Confirm the file access path is AFP (not SMB).
  2. Reproduce:
    • Mount the AFP volume
    • Use Quick Look on an image file (for example, <image_file.tif>)
    • Close Quick Look
  3. Observe:
    • Xinet shows the file as open/in use until unmount/disconnect
  4. Optional isolation test (to confirm it is not Xinet-specific):
    • Test Quick Look against another AFP server implementation (e.g., Netatalk).
    • Check for lingering open handles on the server (for example, using lsof).
  5. # Example (run on the AFP server): search for open handles to a specific file
lsof | grep -i "<image_file.tif>"

Frequently Asked Questions

1. How can I tell if my issue is the same one described here?

You’re likely affected if files accessed over AFP and previewed with macOS Quick Look remain shown as open/in use in Xinet after Quick Look is closed, often clearing only when the AFP volume is unmounted. You may also see: “file is already open by another user or application.”

2. Is this a Xinet server defect that can be patched?

No. In this case the behavior was attributed to macOS Quick Look/Finder behavior over AFP (client/protocol interaction), not a Xinet/ksd defect. The server cannot directly control how Quick Look opens/closes files, so mitigation focuses on client-side preview settings and reducing reliance on AFP for these workflows.

3. What workaround can I apply immediately?

Limit Finder previews to reduce Quick Look-triggered file engagement: Finder → View → Hide Preview, then Finder → View → Show View Options → disable Show icon preview (and similar preview options). Then re-test Quick Look behavior.

4. What’s the recommended longer-term mitigation?

Plan a transition away from AFP for Mac client workflows where Quick Look usage is common (for example, adopt SMB), since AFP + modern macOS preview behavior can lead to lingering open handles/locks.

5. What should I check if disabling previews doesn’t help?

Confirm the share is truly AFP, reproduce with a single test file, and validate whether locks clear only on AFP disconnect/unmount. If possible, run an isolation test against a different AFP server to determine whether the behavior persists outside Xinet; if it does, prioritize protocol migration (e.g., SMB) for impacted users/workflows.

Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Priyanka Bhotika

  2. Posted

Comments