Permissions issue with shared folder using SMB. macOS can't open Linux files, but Linux can open macOS files without issue

Question

Why can't the macOS machine open any files in the shared folder that were transferred from the Linux machine? The permissions seem to be correct. The shared folder is located on the macOS machine / it owns the shared folder.

---

I have a shared folder on macOS Catalina (It's just the default Public folder) that can be accessed by an Ubuntu machine. The share is set up using SMB.

If the Linux machine copies over a photo, text file, whatever into the shared folder, the macOS machine cannot open it. I get a permissions error. If the macOS machine does the same, the Linux machine has no problems whatsoever.

I have tried many settings on macOS to no avail including "Apply to enclosed items".

Here's a screenshot of all the sharing settings on macOS so you can see what I have done.

The first screenshot shows the error when the admin account on macOS tries to open any file that was transferred from the Linux machine. The account has read/write permissions to the shared folder. Even if I copy a file to the macOS desktop, the error persists.

The second screenshot shows Sharing settings in System Preferences. The blacked out parts are just the folder name and the two users who have access to said folder. One user is the macOS admin account, the other user is login credentials for the Linux machine.

The third screenshot is details of the shared folder by right clicking > Get Info.

• macOS Catalina is the machine sharing the folder
• Ubuntu 20.0.4 can see the shared folder and use it without issue
• The machines are connected on a local network
• The Linux machine has it's own login credentials to the shared folder that were set up on the mac. It is not using a "guest" account.

Answer 1

I suspect you have one or more extended attributes set.

These are arbitrary strings or binary metadata about a file. A file can have any number of these, and there are not really any standards for them, except within OS vendors. Thus, Linux can have it's own set, and MacOS can have its own set, explaining the behaviour you observe.

If you want to learn more about these, here is a good resource.

But if you just want to get rid of them, you're going to have to use Terminal commands.

You can try ls -la@ * in your directory to see if any of your files (or more importantly, the directory they live in) have any extended attributes.

If you see something suspicious in the list, you can use xattr -d com.apple.AttributeName * to remove all the extended attributes with the name com.apple.AttributeName — substituting what you think is suspicious for "AttributeName", of course.

You may see a number of com.apple.FinderInfo attributes. They are probably not the problem. That's where the Finder stores things like file tags.

If you report back here what ls -la@ shows you, perhaps we can figure out if this is the problem, and if so, which attributes you should nuke to get rid of it.

Answer 2

In this situation, when the file is transferred, the owner of the file by default is the user which performed the transfer. In this case, this is not the user who owns the shared folder. Also, the basic attributes were not transferred. Instead, the mode bits were set to 0060, which only gives read/write permission to the file owner. In the OP's question, the user who tried opening the file is not the owner of the file. Therefore, permission was denied and the popup message shown the OP's question was presented.

---

I should point out that according to this post, the owner of the file or folder can be determined from the corresponding Finder info window. Under Sharing & Permissions, the owner is the last user shown in the Name column. Note also that the root user will have the name of system.

For example, the image below shows two users: davidanderson and ronjanzen. Since ronjanzen is the last user shown, ronjanzen is the owner of the folder RonShare.