@toddmoore,
I have a much simpler test to try — can you please try downloading/installing our Beta browser and test to see if you are prompted to/if the browsers safe storage gets added to keychain access? Note that downloading/installing the Beta will note interfere or overwrite any information from your current installation.
I switched to the Brave Beta browser, but that did not prompt Keychain Access to add Brave Safe Storage. I am now convinced that the Terminal command provided by Apple on 20 Dec pervasively impacted the data on my computer. Keychain Access has not been modified since that fateful 20 Dec day. Another 20 Dec marker came to my notice. I recently tried to use what is called “new Outlook” to see if that (rather than the “legacy Outlook”) might resolve my various Outlook issues (lack of indexing for email search, dysfunctional calendar reminders). I created a new “sent items” folder in my email inbox, then tried to drag all my sent emails into it. (I did this in an attempt to prompt Outlook and/or Spotlight to index my emails so I can search them again.) When I did so, I noticed that even my emails prior to 20 Dec could not be dragged into the new Sent older. I sent an email on these two 20 Dec markers to Apple (although I think my rep already agrees we do have a pervasive permissions issue). Apparently Apple engineers have not provided updated guidance to my Apple support rep. (I can’t help but wonder if the detailed sequence of Terminal commands you provided might be the sort of resolution Apple should be assisting me in trying?)
Some tests.
In the following testing, the “pwd” command, returns the working directory.
In the following testing, if you respond with answers, be sure to replace
- your username with “username”
- group names with “grpname” (egs. for “user:XYZ” make that “user:grpname”)
You might encounter user names, group names in the ACL results.
An example of ACL results, where you would need to fix a couple names, before you report such findings:
0: user:xyz deny list,add_file,search,delete
1: group:everyone deny delete
2: group:WZCO allow list,add_file,search,delete
I only need to see 3 lines of ACL info, at the most, per test, if they show in results.
–
Folders of interest (and their paths) – all except the first, are either of, or within, your home directory:
/Users/
/Users/[username]/
/Users/[username]/Desktop/
/Users/[username]/Documents/
/Users/[username]/Downloads/
/Users/[username]/Library/
/Users/[username]/Library/Application Support/
/Users/[username]/Library/Keychains/
/Users/[username]/Library/LaunchAgents/
/Users/[username]/Library/Mail/
/Users/[username]/Library/Preferences/
–
But, testing for now, only the following 6 directories:
/Users/[username]/
/Users/[username]/Desktop/
/Users/[username]/Documents/
/Users/[username]/Downloads/
/Users/[username]/Library/
/Users/[username]/Library/Mail/
–
For each directory to be tested, the command lines – explained in order of appearance:
cd – change directory to working directory of interest
pwd – confirms working directory
mkdir – creates a new directory (a new folder) in the working directory, for test purposes
ls -le | grep [case-sensitive_character_string_looking_for_new_folder]
touch – create a new text file in new folder
echo – text string for 1st line in new test file
echo – text string for 2nd line in new test file
ls -le | grep [search_criteria_looking_for_ACL_info] (looking for ACL results, if any) (there are spaces in the criteria)
Where you see double-quotes in a command, include those double-quotes.
–
Testing Desktop folder
cd /Users/[username]/Desktop/
pwd
mkdir TEST_PERMISSIONS
ls -le | grep TEST_PERM
touch /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt
echo “First line” >> /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt
echo “Second line” >> /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt
ls -le | grep " [0-9]: "
Did you encounter a problem? If so, what, and precisely where?
What were the POSIX rwx permissions results for the new TEST_PERMISSIONS folder?
What were the ACL results, if any?
Open the test file, in the TEST_PERMISSIONS folder. Are both text string lines present?
Close the test file.
–
Repeat the test, for each test folder.
–
Regarding your question in your reply 5, above:
Though you may copy a command and paste it into the Terminal.app window . . . the command has to be examined for single quote characters (apostrophes). Such characters must be replaced by your manually typing from your keyboard, so that the “smart” / “curly” single-quote characters
become plain, simple, single-quote characters:
. . . before tapping the Enter / Return key, in order for the plain, simple single-quote characters to be recognized and the command to succeed.
–
Here below are the test results. I substituted [username] in the results.
For each test, I included my template to show each command line I copied into Terminal.
Unless I did something wrong, I found no results at all for POSIX rwx permissions or ACL.
Only 1 of 6 tests resulted in both string lines. The rest were either a blank file or no folder at all.
- Template for /Users/[username]/
cd /Users/[username]/
pwd
mkdir TEST_PERMISSIONS
ls -le | grep TEST_PERM
touch /Users/[username]/TEST_PERMISSIONS/test_file_1.txt
echo “First line” >> /Users/[username]/TEST_PERMISSIONS/test_file_1.txt
echo “Second line” >> /Users/[username]/TEST_PERMISSIONS/test_file_1.txt
ls -le | grep " [0-9]: "
RESULTS:
[username]@[username]16Pro ~ % cd /Users/[username]/
[username]@[username]16Pro ~ % pwd
/Users/[username]
[username]@[username]16Pro ~ % mkdir TEST_PERMISSIONS
mkdir: TEST_PERMISSIONS: File exists
[username]@[username]16Pro ~ % ls -le | grep TEST_PERM
drwxr-xr-x 2 [username] staff 64 Mar 13 15:40 TEST_PERMISSIONS
[username]@[username]16Pro ~ % touch /Users/[username]/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro ~ % echo “First line” >> /Users/[username]/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro ~ % echo “Second line” >> /Users/[username]/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro ~ % ls -le | grep " [0-9]: "
0: group:everyone deny delete (14 Lines of this result)
What were the POSIX rwx permissions results for the new TEST_PERMISSIONS folder? N/A
What were the ACL results, if any? N/A
Open the test file, in the TEST_PERMISSIONS folder. Are both text string lines present? Yes
- Template for /Users/[username]/Desktop/
cd /Users/[username]/Desktop/
pwd
mkdir TEST_PERMISSIONS
ls -le | grep TEST_PERM
touch /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt
echo “First line” >> /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt
echo “Second line” >> /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt
ls -le | grep " [0-9]: "
RESULTS:
[username]@[username]16Pro ~ % cd /Users/[username]/Desktop/
[username]@[username]16Pro Desktop % pwd
/Users/[username]/Desktop
[username]@[username]16Pro Desktop % mkdir TEST_PERMISSIONS
mkdir: TEST_PERMISSIONS: File exists
[username]@[username]16Pro Desktop % ls -le | grep TEST_PERM
drwxr-xr-x 3 [username] staff 96 Mar 13 15:32 TEST_PERMISSIONS
[username]@[username]16Pro Desktop % touch /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro Desktop % echo “First line” >>
zsh: parse error near \n' [username]@[username]16Pro Desktop % /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt zsh: permission denied: /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt [username]@[username]16Pro Desktop % echo “Second line” >> zsh: parse error near
\n’
[username]@[username]16Pro Desktop % /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt
zsh: permission denied: /Users/[username]/Desktop/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro Desktop % ls -le | grep " [0-9]: "
0: group:everyone deny delete (16 Lines of this result)
What were the POSIX rwx permissions results for the new TEST_PERMISSIONS folder? N/A
What were the ACL results, if any? N/A
Open the test file, in the TEST_PERMISSIONS folder. Are both text string lines present? Blank
- Template for /Users/[username]/Documents/
cd /Users/[username]/Documents/
pwd
mkdir TEST_PERMISSIONS
ls -le | grep TEST_PERM
touch /Users/[username]/Documents/TEST_PERMISSIONS/test_file_1.txt
echo “First line” >> /Users/[username]/Documents/TEST_PERMISSIONS/test_file_1.txt
echo “Second line” >> /Users/[username]/Documents/TEST_PERMISSIONS/test_file_1.txt
ls -le | grep " [0-9]: "
RESULTS:
[username]@[username]16Pro Desktop % cd /Users/[username]/Documents/
[username]@[username]16Pro Documents % pwd
/Users/[username]/Documents
[username]@[username]16Pro Documents % mkdir TEST_PERMISSIONS
[username]@[username]16Pro Documents % ls -le | grep TEST_PERM
drwxr-xr-x 2 [username] staff 64 Mar 13 16:23 TEST_PERMISSIONS
[username]@[username]16Pro Documents % touch /Users/[username]/Documents/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro Documents % echo “First line” >>
zsh: parse error near \n' [username]@[username]16Pro Documents % /Users/[username]/Documents/TEST_PERMISSIONS/test_file_1.txt zsh: permission denied: /Users/[username]/Documents/TEST_PERMISSIONS/test_file_1.txt [username]@[username]16Pro Documents % echo “Second line” >> zsh: parse error near
\n’
[username]@[username]16Pro Documents % /Users/[username]/Documents/TEST_PERMISSIONS/test_file_1.txt
zsh: permission denied: /Users/[username]/Documents/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro Documents % ls -le | grep " [0-9]: "
0: group:everyone deny delete (30 Lines of this result)
What were the POSIX rwx permissions results for the new TEST_PERMISSIONS folder? N/A
What were the ACL results, if any? N/A
Open the test file, in the TEST_PERMISSIONS folder. Are both text string lines present? Blank
- Template for /Users/[username]/Downloads/
cd /Users/[username]/Downloads/
pwd
mkdir TEST_PERMISSIONS
ls -le | grep TEST_PERM
touch /Users/[username]/Downloads/TEST_PERMISSIONS/test_file_1.txt
echo “First line” >> /Users/[username]/Downloads/TEST_PERMISSIONS/test_file_1.txt
echo “Second line” >> /Users/[username]/Downloads/TEST_PERMISSIONS/test_file_1.txt
ls -le | grep " [0-9]: "
RESULTS:
[username]@[username]16Pro Documents % cd /Users/[username]/Downloads/
[username]@[username]16Pro Downloads % pwd
/Users/[username]/Downloads
[username]@[username]16Pro Downloads % mkdir TEST_PERMISSIONS
[username]@[username]16Pro Downloads % ls -le | grep TEST_PERM
drwxr-xr-x 2 [username] staff 64 Mar 13 19:00 TEST_PERMISSIONS
[username]@[username]16Pro Downloads % touch /Users/[username]/Downloads/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro Downloads % echo “First line” >>
zsh: parse error near \n' [username]@[username]16Pro Downloads % /Users/[username]/Downloads/TEST_PERMISSIONS/test_file_1.txt zsh: permission denied: /Users/[username]/Downloads/TEST_PERMISSIONS/test_file_1.txt [username]@[username]16Pro Downloads % echo “Second line” >> zsh: parse error near
\n’
[username]@[username]16Pro Downloads % /Users/[username]/Downloads/TEST_PERMISSIONS/test_file_1.txt
zsh: permission denied: /Users/[username]/Downloads/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro Downloads % ls -le | grep " [0-9]: "
0: group:everyone deny delete (910 Lines of this result)
What were the POSIX rwx permissions results for the new TEST_PERMISSIONS folder? N/A
What were the ACL results, if any? N/A
Open the test file, in the TEST_PERMISSIONS folder. Are both text string lines present? Blank
- Template for /Users/[username]/Library/
cd /Users/[username]/Library/
pwd
mkdir TEST_PERMISSIONS
ls -le | grep TEST_PERM
touch /Users/[username]/Library/TEST_PERMISSIONS/test_file_1.txt
echo “First line” >> /Users/[username]/Library/TEST_PERMISSIONS/test_file_1.txt
echo “Second line” >> /Users/[username]/Library/TEST_PERMISSIONS/test_file_1.txt
ls -le | grep " [0-9]: "
RESULTS:
[username]@[username]16Pro Downloads % cd /Users/[username]/Library/
[username]@[username]16Pro Library % pwd
/Users/[username]/Library
[username]@[username]16Pro Library % mkdir TEST_PERMISSIONS
[username]@[username]16Pro Library % ls -le | grep TEST_PERM
drwxr-xr-x 2 [username] staff 64 Mar 13 19:11 TEST_PERMISSIONS
[username]@[username]16Pro Library % touch /Users/[username]/Library/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro Library % echo “First line” >>
zsh: parse error near \n' [username]@[username]16Pro Library % /Users/[username]/Library/TEST_PERMISSIONS/test_file_1.txt zsh: permission denied: /Users/[username]/Library/TEST_PERMISSIONS/test_file_1.txt [username]@[username]16Pro Library % echo “Second line” >> zsh: parse error near
\n’
[username]@[username]16Pro Library % /Users/[username]/Library/TEST_PERMISSIONS/test_file_1.txt
zsh: permission denied: /Users/[username]/Library/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro Library % ls -le | grep " [0-9]: "
0: group:everyone deny delete (92 Lines of this result)
What were the POSIX rwx permissions results for the new TEST_PERMISSIONS folder? N/A
What were the ACL results, if any? N/A
Open the test file, in the TEST_PERMISSIONS folder. Are both text string lines present? N/A
- Template for /Users/[username]/Library/Mail/
cd /Users/[username]/Library/Mail/
pwd
mkdir TEST_PERMISSIONS
ls -le | grep TEST_PERM
touch /Users/[username]/Library/Mail/TEST_PERMISSIONS/test_file_1.txt
echo “First line” >> /Users/[username]/Library/Mail/TEST_PERMISSIONS/test_file_1.txt
echo “Second line” >> /Users/[username]/Library/Mail/TEST_PERMISSIONS/test_file_1.txt
ls -le | grep " [0-9]: "
RESULTS:
[username]@[username]16Pro Library % cd /Users/[username]/Library/Mail/
[username]@[username]16Pro Mail % pwd
/Users/[username]/Library/Mail
[username]@[username]16Pro Mail % mkdir TEST_PERMISSIONS
mkdir: TEST_PERMISSIONS: Operation not permitted
[username]@[username]16Pro Mail % ls -le | grep TEST_PERM
ls: .: Operation not permitted
[username]@[username]16Pro Mail % touch /Users/[username]/Library/Mail/TEST_PERMISSIONS/test_file_1.txt
touch: /Users/[username]/Library/Mail/TEST_PERMISSIONS/test_file_1.txt: No such file or directory
[username]@[username]16Pro Mail % echo “First line” >>
zsh: parse error near \n' [username]@[username]16Pro Mail % /Users/[username]/Library/Mail/TEST_PERMISSIONS/test_file_1.txt zsh: no such file or directory: /Users/[username]/Library/Mail/TEST_PERMISSIONS/test_file_1.txt [username]@[username]16Pro Mail % echo “Second line” >> zsh: parse error near
\n’
[username]@[username]16Pro Mail % /Users/[username]/Library/Mail/TEST_PERMISSIONS/test_file_1.txt
zsh: no such file or directory: /Users/[username]/Library/Mail/TEST_PERMISSIONS/test_file_1.txt
[username]@[username]16Pro Mail % ls -le | grep " [0-9]: "
ls: .: Operation not permitted
What were the POSIX rwx permissions results for the new TEST_PERMISSIONS folder? N/A
What were the ACL results, if any? N/A
Open the test file, in the TEST_PERMISSIONS folder. Are both text string lines present? N/A
Sit tight. I happened to grab what you wrote here. Let me study it.
–
Re your results, you did get POSIX rwx permissions. Example from the first test (I offset the command line and result):
and also, for the first test, an ACL result (the "0: group: everyone . . .) line for the command given:
BTW, for this particular first test, the POSIX rwx type of permissions look good, for your ease of use of folder “TEST_PERMISSIONS”. But I am uncertain about what other ACL permissions (other than you found and reported) probably exist.
–
Okay. I copied/pasted the results via the website. There was nothing really wrong in the post, but I saw that some of the lines “wrapped” to the next line in my post. I was going to try copying the results in an email reply instead to see if the appearance was better. However, if you grabbed the initial reply and think it is readable, I will hold off.
UPDATED 20220314 Monday
–
Quit all applications except Terminal.app
Given:
- a file [file name]
- a folder [folder name]
- a parent directory name [parent dir name]
- path to parent directory for a file [path to parent dir]
- path to parent directory for a folder [path to parent dir]
–
To learn the POSIX rwx type of permissions of specific items in a parent directory:
cd /[path to parent dir]/[parent dir name]/
ls -al . | grep “[file name]”
ls -al . | grep “[folder name]”
or
ls -al . (notice trailing period character - keep a lookout for those)
and then scroll up / down to find the item of interest
–
To learn the POSIX rwx type of permissions and ACL permissions of items in a parent directory:
cd /[path to parent dir]/[parent dir name]/
ls -ale .
and then scroll up / down to find the item of interest. ACL results (if any) will immediate follow the line that contains the item of interest; example:
drwxr-xr-x+ 5 username staff 170 Mar 14 03:10 TEST_PERMISSIONS
0: group:WORKGROUP allow read
1: user:username allow list,add_file,search,delete
The + sign, there at the end of drwxr-xr-x means that some ACL exists for, and within, the directory.
–
If you want to clear away the ACL permissions for a specific item:
cd /[path to parent dir]/[parent dir name]/
sudo chmod -N “[file name]”
sudo chmod -N “[folder name]”
–
If you want to thoroughly clear away the ACL permissions for the parent directory and its contents:
cd /[path to parent dir]/
sudo chmod -R -N “[parent dir name]”
–
If you want to clear away the ACL permissions only for the contents of the parent directory:
cd /[path to parent dir]/[parent dir name]/
sudo chmod -R -N .
–
About the immutable flag
“The immutable flag is an extended file system attribute, and can be set on both files and directories. With this flag in place, the file or directory cannot be modified, renamed or deleted without first removing the immutable flag. Setting this flag requires root privileges.”
Ref.: “https://www.rootusers.com/prevent-file-directory-modification-deletion-renaming-linux/”
–
How to remove the immutable flag for a parent directory and all of its contents
cd /[path to parent dir]/
sudo chflags -R nouchg “[parent dir name]”
–
FIXES
I suspect that the immutable flags are the greater problem; but ACL certainly would be the next problem to address, if clearing the immutable flags does not accomplish the job of restoring control of your computer files and work to you.
When you are prepared, after backing up your data, then you might begin to fix things as follows.
Remove the immutable flags for the Library folder of your home directory and all its contents:
cd /Users/[username]/
sudo chflags -R nouchg “Library”
And the same, for the Desktop, Documents, and Downloads folders of your home directory.
cd /Users/[username]/
sudo chflags -R nouchg “Desktop”
sudo chflags -R nouchg “Documents”
sudo chflags -R nouchg “Downloads”
Quit Terminal.app
Restart the Mac.
Start up Brave Browser. That might establish the “Base Safe Storage” entry in the Keychain. Take a look.
IF not, then work at establishing the “Base Safe Storage” entry in the Keychain, per previous instructions in the earlier reply above on this web page.
–
Thanks. I will do just as you advice (remove the immutable flags, see if that works, and if necessary go through the #34 instructions).
I did find some external space to do backup of important folders in my user/username/ folder and also a copy of my applications folder. However, I was not able to backup my Macintosh HD Library. When I tried to copy that folder it said, “The operation can’t be completed because you don’t have permission to access some of the items.” Is there a permissions command to resolve that issue or should I rely on my Time Machine backup for now (assuming Time Machine backs that up ;>)
“you don’t have permission” – figures. Stripping away the immutable flags might (probably will) solve that.
–
A backup workaround:
Let us say, you use the Finder to create a new folder “BKUPS_COLLECTION” as a (good enough for now) backup collection:
/Users/[username]/Documents/BKUPS_COLLECTION/
You could use the following Terminal window, ditto command, to back up your Keychains folder:
ditto -c -k -X --sequesterRsrc --keepParent “/Users/[username]/Library/Keychains” “/Users/[username]/Documents/BKUPS_COLLECTION/20220314_Keychains_bkup.zip”
That particular ditto command string, creates a .zip compressed file. I added a date string to the resulting file name, for ease of reference.
Be sure to look in the ~/Documents/BKUPS_COLLECTION/ folder, and verify that the .zip file showed up there (confirming that you did not botch the command):
/Users/[username]/Documents/BKUPS_COLLECTION/20220314_Keychains_bkup.zip
Test the ditto command string work, by double-clicking on that .zip file. That should expand the .zip file and produce a “Keychains” folder:
/Users/[username]/Documents/BKUPS_COLLECTION/Keychains/
Open that “Keychains” folder, in order to verify that its contents appear to be OK. Thus, you confirmed the ditto command’s work.
-OR-
Instead of using the fancy ditto command, you could use the Compress . . . selection under the Finder menu bar > File menu.
For example, Compress the “Keychains” folder and drag the resulting “Keychains.zip” file, into the ~/Documents/BKUPS_COLLECTION/ folder.
–
Your .zip compression attempts, might run into the “you don’t have permissions” problem, but do try.
If you cannot .zip compress, then take your first swing at the immutable flags:
cd ~/Library
sudo chflags -R nouchg “Keychains”
And then try the .zip compression.
–
To make a long story short. I think the permissions issue is resolved.
The Apple rep called and viewed my desktop. We followed your instructions in 48 above (immutable flags). Since that did not fix Brave, we followed your instructions in 34 above (ACL). Following two commands plus the restart seems to have fixed the issue:
sudo chflags -R nouchg /Users/[username]/
sudo chmod -R -N /Users/[username]/
Restart
Now Brave accepts passwords. Plus, the other permissions related issues that plagued me also seem to be gone. Apple and Outlook calendars are functional. I can move and discard files without using my password. 1Password app will now respond to my Touch ID too.
I only have three known issues remaining - which I suppose are not permissions issues - at least on the two out of three levels dealt with by your instructions. I am mentioning these FYI since I think Brave is fixed. So, I realize these are not your problem. (But maybe can’t hurt to ask, right?).
- The original issue I was dealing with Apple with (before the fateful Terminal command on 20Dec that impacted my permissions for some yet unknown reason) is that “File Sharing” will not remain checked in System Preferences (Sharing) after restart. This issue was inherited from my old laptop and migrated into the new laptop. It seems minor compared to what you just fixed. This issue seems to be a mystery and has defied efforts to resolve it so far.
- After the last Migration Assistant resolution attempt supervised by Apple, MS Outlook email search is will not function. My email returns a blank with “No Results” in a search for emails (that I know and can see are there). I can get some alternative ability to search my email by using Spotlight.
- Any given Finder window on my Mac will only search “This Mac” but will not search specific folders beyond that (even when I know the file is in a given folder, the Finder search window goes blank).
Congrats. Glad you pursued the fix. Takes some daring; but you gain some confidence about the Mac engineering spaces.
–
File Sharing
Go to System Preferences and take screenshots (as you believe necessary; be thorough re Firewall settings) of the settings for three panes:
- Security & Privacy (tabs: General / FileVault / Firewall - be thorough)
- Network (the Location you use and its settings)
- Sharing (enabled services important to you and their settings)
Quit everything. Move the following files:
- “com.apple.alf.plist”
- “com.apple.AppleFileServer.plist”
. . . located at:
/Library/Preferences/com.apple.alf.plist
/Library/Preferences/com.apple.AppleFileServer.plist
. . . to the Desktop. Restart the Mac.
Check the folder:
/Library/Preferences/
Two new replacement files should be there.
Go to System Preferences and examine the three panes. Fix settings as you believe necessary. Be thorough re Firewall settings.
Re File Sharing settings, fill in details in the various settings for sharing that you need and will keep Enabled. I suggest that you might also set up for sharing that may occur but leave that sharing Disabled until you need it running.
- designate the folders to be shared
- specify the users and groups who will have access
A group would be one of YOUR creation. Let us say, you create a group named “TM”. Users on three networked computers, who are also members of TM, will have access when you
- list the TM group among the users allowed to have access
- be certain that the TM group ID value is the same used for each TM group on the other networked computers
(You see “TM” – but the OS and networking software observes the ID values for the group.)
Click Options and continue. Be specific with the Options - Enable protocols and users, that are necessary.
–
That might be fixed, by chance, of the two replaced files mentioned previously.
–
Searching on Mac’s and attached / connected drives and network shares:
EasyFind
–
Thank you. I downloaded EasyFind - and like it!
RE: File Sharing
I tried the two Library prefs procedure and then restarted, but that didn’t work to resolve file sharing being unchecked upon restart.
Please note - I did drag the files to the desktop. However, at least one of the files (com.apple.alf.plist) replaces itself immediately - as soon as it is dragged out. I think even the other file behaved this way at one point too.
So I tried it again a third time - this time trashing the files (so they did not re-appear immediately) and then restarting.
When I did this, the com.apple.alf.plist replaced itself in the prefs folder -
but com.apple.AppleFileServer.plist file did not.
In order to even open Sharing, I had to drag the old copy of AppleFileServer back.
In no case were any of the preferences refreshed or changed in any way. They were exactly way they were - and file sharing is still not checked after restart. As I mentioned, this issue was something I lived with in my old mac and I was disappointed that it migrated via Assistant into the new mac.
TinkerTool System:
One of the screenshots:
–
To Enable File Sharing
In System Preferences > Sharing >
Start with the Options button in the Sharing window, followed by the resulting pop-down window
Enable the SMB selection
IF AFP selection exists (Monterey?), Enable it.
Add / Select Account(s) for Windows File Sharing. (I am not certain what that window looks like, now - Monterey?)
When you click the “Done” button. Fill in the Shared (folders) and the Users in the Sharing window.
At some moment in all that, the “File Sharing” selection will become Enabled.
–
com.apple.AppleFileServer.plist
Locations:
/Library/Preferences/com.apple.AppleFileServer.plist
/System/Library/LaunchDaemons/com.apple.AppleFileServer.plist
If File Sharing (AFP) is Enabled, then the following command
sudo launchctl list | grep “com.apple.AppleFileServer”
will have “com.apple.AppleFileServer” in the result; example:
0 com.apple.AppleFileServer
–
com.apple.smbd.plist
Location:
/System/Library/LaunchDaemons/com.apple.smbd.plist
If File Sharing (SMB) is Enabled, then the following command
sudo launchctl list | grep ‘.*com.apple.smbd$’
will have “com.apple.smbd” in the result; example:
0 com.apple.smbd
–
There might be some immutable flags. Look for ACL permissions – use the feature in TinkerTools System 7. But I would not be hasty without studying the ACL and learning what you can elsewhere online.
DO NOT mess with permissions anywhere within the /System folder.
But you might remove an immutable flag (if it exists?) for:
com.apple.AppleFileServer.plist at
/Library/Preferences/com.apple.AppleFileServer.plist
I am not sure about that.
–
UPDATED 20220316 Wednesday evening
Two “defaults read” commands for your Terminal window.
First “defaults read” command looks for the “com.apple.AppleFileServer” key in file: “disabled.plist”:
defaults read /private/var/db/com.apple.xpc.launchd/disabled.plist com.apple.AppleFileServer
Response 0 - (not disabled)
Response 1 = (disabled)
A response of 0 means that the launchd process of Mac OS will launch AppleFileServer some time during startup.
–
Second “defaults read” command looks for the “com.apple.smbd” key in the same file: “disabled.plist”:
defaults read /private/var/db/com.apple.xpc.launchd/disabled.plist com.apple.smbd
Response 0 - (not disabled)
Response 1 = (disabled)
A response of 0 means that the launchd process of Mac OS will launch smbd some time during startup.
NOTE about launchd process. Start up the Mac’s Activity Monitor utility, and look for “launchd” in the list of Process Names . . . you will see that the Process ID (PID) for “launchd” is very low, usually 1, and the kernel PID is 0. Mac OS uses launchd to launch many processes.
Please run both of the “defaults read” commands on your wife’s Mac. And on your old Mac (if you can).
–
Locations to look at, for com.apple.AppleFileServer.plist
/Library/LaunchAgents/
/Library/LaunchDaemons/
/Library/Preferences/
/System/Library/LaunchAgents/
/System/Library/LaunchDaemons/
/System/Library/Preferences/
/Users/[username]/Library/LaunchAgents/
/Users/[username]/Library/Preferences/
–
NOTE: the tilde character usage – both of the following represent the same directory:
~/Library/LaunchAgents/
/Users/[username]/Library/LaunchAgents/
Both of the following represent the same directory:
~/
/Users/[username]/
No tilde character:
/Library/
That is the “Library” folder at the root level, along with folders:
/Applications/
/System/
/Users/
–
Wow – Guess who just installed TinkerTool 7 just prior to reading your suggestion!
I did try TinkerTool’s fix system prefs feature – but that did not fix the issue either.
Terminal shows just smbd is enabled on my 16” laptop.
I have just one AppleFileServer.plist file in my laptop: /Library/Preferences/com.apple.AppleFileServer.plist
I attached a screenshot of what TinkerTool (TT) shows as the ACL permissions for that file (just in case these appear correct or show some need).
BTW – I have no such file in System/Library/LaunchDaemons. (Yet my wife’s new 14” laptop with Monterey doesn’t have one there either and her file sharing has no issues.)
TT has a section in ACL to reset home permissions – but I am afraid to use it since I didn’t know if that was the type of command that may have caused the 3 month permissions issue via terminal on 20 Dec.
Just so we are clear on this Sharing issue - my file sharing will not remain checked “on” after restart. I have to remember to go into Sharing after any restart and check the box. Then sharing works. It just will not remain on after any restart.
On the other hand (and in comparison to the other plist file), the “Effective Permissions” tab of TT (for my username) shows a lot more red flags for the /Library/Preferences/com.apple.alf.plist file – see attached.
I think what you are saying, is, the File Sharing service checkbox setting, if Enabled (checked) . . . does not stick.
For example, if you Shut Down the Mac, or Restart the Mac, and next, (the Mac is starting) . . . next, the Mac settles down after starting . . . and you look at the System Preferences > Sharing window . . . the File Sharing service checkbox setting is Disabled (un-checked).
And possibly the DOES NOT STICK also occurs during a Log out / Log in test?
When non-STICK, have settings with the Options, change? If so, which?
–
That setting has been known to NOT STICK (sometimes).
Some users (including myself) sometimes found that, after setting the various File Sharing entries / settings / switches (as previously mentioned), then closing and Quitting the System Preferences . . . and thereupon going back to look at your effort, you might find something did not stick.
Sometimes, it helps to be sure to Click the Lock before closing the Sharing window (and thus, returning to the System Preferences window).
Sometimes, you need to do that, and then go thru a Log out / Log in cycle.
BTW, the non-STICK problem, is why I began to work the settings from the inside, starting with the Options. For some reason, that tilts the outcome toward what is expected. YMMV.
–
One thing to double-check, is what I mentioned in an earlier reply 52, re
Security & Privacy (tabs: General / FileVault / Firewall - be thorough)
Using your wife’s new Mac, plus your old Mac, as references, look at your new Mac . . . and compare the settings, particularly the Firewall.
Your Firewall might not allow AFP, but your old Mac and your wife’s new Mac, do?
–
Your wrote:
I have just one AppleFileServer.plist file in my laptop:
/Library/Preferences/com.apple.AppleFileServer.plist
Does your wife’s new Mac have that file, too?
–
Please check the ACL – use TT “Effective Permissions” – for the “com.apple.AppleFileServer.plist” file:
/Library/Preferences/com.apple.AppleFileServer.plist
. . . and a few of the files near that file (Finder > List view).
Please check the ACL – use TT “Effective Permissions” – for the “Preferences” folder:
/Library/Preferences/
–
PS. I updated the tail end of my reply 54