Genuinely strange MacOS permissions issue: Folders with red minus signs

[stiphout]

Hi all! I'm fairly new to TrueNAS, and NAS's in general. Fairly familiar with linux and macos, somewhat familiar with permissions, ACLs, etc.

BLUF: Mounting some SMB shares on MacOS work fine, but getting Finder "red circles with minus signs" when mounting some other shares:

I have a single pool, with multiple datasets. At some point, mounting newer datasets started messing with the mounting of older datasets. So I seem to have two "classes" of datasets, as far as this weird behavior is concerned. Call them Class-One and Class-Alpha. But I can't tell any difference between the datasets in these two classes, other than that I can figure out which class a dataset is in by mounting multiple datasets and seeing which ones are getting screwed up. The only pattern I can find is that I created all the Class-One datasets first, and I'm not able to create any more that end up being in this class.

Here's the crux of the weirdness: If I mount one or more datasets in Class-One, they all work fine. But as soon as I mount ANY dataset in Class-Alpha, ALL of the mounted Class-One datasets become ... "pseudo-read-only." And if I mount any more Class-One datasets, they will be pseudo-read-only. The only way to mount Class-One datasets again is to unmount EVERY SMB share on that server, and then mount ONLY Class-One shares again.

E.g., I can mount dataset ds1, and access the files there just fine. I can then mount ds2, and again, everything's hunky dory. But then if I mount dataset dsA, or dsB (you get the idea), both the ds1 and ds2 mounts become immediately pseudo-read-only. And if I mount ds3, it will be pseudo-read-only too. If I then unmount dsA, dsB, ds1, ds2, and ds3... and then remount ds1, ds2, and/or ds3, then they're fine again. Until I try to mount, say, dsA. See the pattern?

Oh, and by pseudo-read-only I mean all the folders in the shared directory have those little red circles with a white minus sign on them, and if I double-click on one (such as MyFolder), I get this error:

The folder "MyFolder" can't be opened because you don't have permission to see its contents.

BUT. Here's where it gets more strange.

If I open up terminal, and do a folder listing on EITHER class of mounted dataset, it works! And there is no difference between them:

Code:

myuser@mymac ~ % cd /Volumes/ds1
myuser@mymac ds1 % ls -l
drwx------  1 myuser  staff  16384 Apr  9 18:59 MyFolder
drwx------  1 myuser  staff  16384 Apr  9 18:38 AnotherFolder
drwx------  1 myuser  staff  16384 Apr  9 18:44 SomeStuff
drwx------  1 myuser  staff  16384 Apr  9 18:46 MoreStuff
myuser@mymac ds1 % cd ../dsA && ls -l
drwx------  1 myuser  staff  16384 Apr  8 12:35 YetAnotherFolder
drwx------  1 myuser  staff  16384 Apr 10 17:05 SomeFilesIMade
drwx------  1 myuser  staff  16384 Apr  8 12:35 StorageForThings
drwx------  1 myuser  staff  16384 Apr  8 12:35 StorageForThingies
drwx------  1 myuser  staff  16384 Apr 11 10:46 NotStorageJustKidding
myuser@mymac dsA % 

I CAN access all of these directories using terminal, and I can access any of the files in any of the subdirectories (using terminal)! But not using finder. If I open up a finder window using...

Code:

myuser@mymac ds1 % open MyFolder

...the window WILL open, somewhat inconsistently. I can access folders of arbitrary depth in this way. Sometimes they open up and immediately "self-navigate" up to the first non-red-circle folder (in this case, ds1). But sometimes it merrily displays MyFolder just fine, although any folders therein have their red circles.

FILES displayed in finder windows in this way do NOT have red circles, and double-clicking on one will open the file in the associated app. I can edit them, too. But if I "spacebar" on one to preview it, this usually kicks the parent folder up to the first non-red-circle folder. The file is momentarily previewed if it is small, but then I'm left with a preview of the red-circle folder to which I just got navigated.

So. Weird, yes?

Note that if I ssh into my TrueNAS box, I can ls -l on the files/folders in either dataset and the permissions there are indistinguishable from each other. So. Ugh.

Code:

truenas% cd /mnt/myonlypool/
truenas% ls -l
drwxrwx---+  7 nasuser   nasuser   7 Apr 11 09:52 ds1
drwxrwx--x+ 11 nasuser   nasuser   7 Apr 11 10:40 ds2
drwxrwx---+  6 nasuser   nasuser  11 Apr 11 17:42 dsA
drwxrwx---+  6 nasuser   nasuser  11 Apr 11 17:42 dsB
truenas% ls -l ds1/
drwxrwx---+  2 nasuser   nasuser  43 Mar 31 10:11 MyFolder
drwxrwx---+  7 nasuser   nasuser   8 Apr 11 16:32 AnotherFolder
drwxrwx---+ 20 nasuser   nasuser  25 Apr  3 22:28 SomeStuff
drwxrwx---+ 30 nasuser   nasuser 690 Apr  8 13:55 MoreStuff
truenas% ls -l dsA/
drwxrwx---+ 20 nasuser   nasuser  20 Apr  9 18:59 YetAnotherFolder
drwxrwx---+  9 nasuser   nasuser  10 Apr  9 18:38 SomeFilesIMade
drwxrwx---+  3 nasuser   nasuser   4 Apr  9 18:44 StorageForThings
drwxrwx---+  2 nasuser   nasuser   2 Apr  9 18:46 StorageForThingies
drwxrwx---+  3 nasuser   nasuser   4 Apr  9 18:49 NotStorageJustKidding
truenas%{/CODE]

My question: How do I troubleshoot this? Where are the errors getting logged? And of course, how do I "fix" the old Class-One datasets?

Thanks everyone!

-Dutch

 

[stiphout]

My question: How do I troubleshoot this? Where are the errors getting logged? And of course, how do I "fix" the old Class-One datasets?

Thanks everyone!

-Dutch

 

[stiphout]

To quote Cloudy With A Chance of Meatballs 2: "I saved myself!"

I just needed to delete the Class-One shares in the Sharing->Windows Shares (SMB) list... and then recreate them. No changes. Just delete and recreate. The weirdness disappeared.

Le sigh.

 

[cwagz]

Sorry to bring up this older topic.

I just got my first mac computer and ran into this same issue. It occurred right after I created a share in TrueNAS Bluefin RC1 for time machine to use. Lightroom can write to its volume on TrueNAS just fine but if I open the volume in Finder it shows the red stop signs and says I do not have permission to see the contents.

Unmounting and then remounting the shares will work until I mount the Time Machine volume. Then I will have red stop signs on all the folders again.

All of my regular shares are using nfsv4 acls. The time machine share is using POSIX acls.

Any ideas or further resolution on this?

 

[anodos]

Sorry to bring up this older topic.

I just got my first mac computer and ran into this same issue. It occurred right after I created a share in TrueNAS Bluefin RC1 for time machine to use. Lightroom can write to its volume on TrueNAS just fine but if I open the volume in Finder it shows the red stop signs and says I do not have permission to see the contents.

Unmounting and then remounting the shares will work until I mount the Time Machine volume. Then I will have red stop signs on all the folders again.

All of my regular shares are using nfsv4 acls. The time machine share is using POSIX acls.

Any ideas or further resolution on this?

If you look at properties in MacOS does it show files / dirs as 'locked'? Maybe PM me a debug.

 

[cwagz]

I got home and updated to Bluefin release and Ventura 13.1 before seeing this. Everything is working normally now so far. I will post back if this crops back up. Maybe some of the Mac fixes in Bluefin release took care of it.

 

[anodos]

I got home and updated to Bluefin release and Ventura 13.1 before seeing this. Everything is working normally now so far. I will post back if this crops back up. Maybe some of the Mac fixes in Bluefin release took care of it.

The default for fruit:zero_file_id changed in samba 4.17 to enable it by default. In our RC cycle this parameter proved to be problematic for many MacOS clients and so we reverted it. MacOS SMB client relies on MS-FSCC file ids for internal vnode cache IIRC. Returning a basically NULL fileid is supposed to prompt the OS to internally allocate them and not rely on remote server, this has proven to be somewhat unreliable (causing Finder crashes in Big Sur and earlier and erratic behavior in later versions).

 

[cwagz]

The default for fruit:zero_file_id changed in samba 4.17 to enable it by default. In our RC cycle this parameter proved to be problematic for many MacOS clients and so we reverted it. MacOS SMB client relies on MS-FSCC file ids for internal vnode cache IIRC. Returning a basically NULL fileid is supposed to prompt the OS to internally allocate them and not rely on remote server, this has proven to be somewhat unreliable (causing Finder crashes in Big Sur and earlier and erratic behavior in later versions).

I have not seen the folders show up with the red stop sign mark yet. The transfer speeds are terrible though. It took a solid hour or more for Lightroom to close yesterday writing a 800MB backup to my Lightroom share on TrueNAS.

I also noticed while using a gigabit wired adapter to copy 3GB video files that I was getting less than 10MB/s. Everything else in my house can transfer at line speed easily to TrueNAS.

The weird thing was that I had walked away and when I came back the machine may have been asleep. All the copies after I woke it up seemed to be at line speed.

I am very new to macOS so I am using the activity monitor to see the network rates.

I actually thought Lightroom crashed and only after looking at the backup file properties on the server could see that the file size was growing at an unbelievable slow rate.

Let me know if I should start a new thread or send you any info. I have seen posts around the internet about Ventura having smb issues.