Unexpected Permission denied error on file sharing volume

Question

Created Nov ’24

Replies 16

Boosts 0

Participants 2

I am getting recurring errors running code on macOS 15.1 on arm that is using a volume mounted from a machine running macOS 14.7.1 on x86. The code I am running copies files to the remote volume and deletes files and directories on the remote volume. The files and directories it deletes are typically files it previously had copied.

The problem is that I get permission failures trying to delete certain directories.

After this happens, if I try to list the directory using Terminal on the 15.1 system, I get a strange error:

ls -lA TestVAppearances.app/Contents/runtime-arm/Contents
total 0
ls: fts_read: Permission denied

If I try to list the directory on the target (14.7.1) system, there is no error:

TestVAppearances.app/Contents/runtime-arm/Contents:
total 0

Answered by DTS Engineer in 819722022

I am somewhat surprised that moving the application to a directory that is not and has never been displayed by Finder (before trying to delete the application) does not fix the problem.

There's an odd difference in the listing output that might explain the issue. The values for "runtime-arm" match:

Client:
drwxr-xr-x@ 1 alan  staff  16384 Dec  8 09:37 runtime-arm

Server
drwxr-xr-x@ 3 alan  staff  102 Dec  8 09:37 runtime-arm

But the values for the contents of "runtime-arm" do NOT match:

Client: 
drwxr-xr-x  1 alan  staff  16384 Dec 12 11:34 Contents

Server:
drwxr-xr-x@ 2 alan  staff  68 Dec 12 11:34 Contents

The "@" symbol above indicates that an extended attribute has been attached, so what does the command: " xattr -lx <path> " return for the 4 objects above?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

1w

Hi,

I tried to replicate the situation on the server, but the newly copied application files do not have xattrs,

Copied from the client to the server? What copied the files? This particular attribute is used to track the "source" of file, so it will change (or be removed) depending on what actually interacts with the file.

In addition:

The file that I described had a value of 01 02 00 F5 28 1A 84 40 15 BA C9 when I inspected it on the server.

The contents of that data include a machine specific reference to the source app, so the data is only valid on the source machine.

However, its current value is empty. Other files in that application had the same attribute and it seems they all now have empty values.

How is the file actually being copied?

This issue here is that while the term "copy" is obviously widely used, "copying" isn't really something any file system actually defines, nor is there any coherent/standard definition of what constitutes a "copy" of a file (particularly across file systems). Ultimately, every copy engine/implementation has to make a long series of decisions, choosing what data to preserve and which it discard. I'm concerned that you're getting an empty value here because the engine is trying to blindly copy "everything", is not a very good idea (with this xattr being one example).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0