Newly assigned objects.nosync folder on desktop after updating to 11.3

[Lihp8270]

I got a relocated items folder too. No pdf in there, just the group.system_default file.

When I ran the diff command posted by Kallt

I get the following output

140a141
> _trustd:*:282:_trustd

Can I just leave it be and ignore it? Or is there something that I need to do?

 

[Ghostrider72]

It says so in the accompanying PDF file:


There is a file called /private/etc/group that deviates from Apple’s default. Apple chose to keep that file there and put the default file in “Relocated Items” and added “system_default” to the name.

Given that Apple leaves you a choice, it is probably fine to just ignore or delete the Relocated Items folder. Otherwise, you’d have to compare the two files:

diff /etc/group /Users/Shared/Relocated\ Items/Configuration/private/etc/group.system_default

and merge the changes manually. In my case, I only have to add this line to /etc/group:

_trustd:*:282:_trustd

New macbook air user here. That's very technical for an operative system that should be user friendly. To me, it makes no sense and will live forever with this folder on the desktop not knowing if deleting it will make the system unreliable, will cause an explosion or any other damage. You know, it's an upgrade, do they expect the average user to technically operate on the system?

 

[panzerboy]

New macbook air user here. That's very technical for an operative system that should be user friendly. To me, it makes no sense and will live forever with this folder on the desktop not knowing if deleting it will make the system unreliable, will cause an explosion or any other damage. You know, it's an upgrade, do they expect the average user to technically operate on the system?

You are right, this should not be happening.

However, in this particular case, as mentioned by other people in this thread, you can safely delete the folder from the desktop.

 

[metabotschafter]

In the end, its a kind of bug/mistake.

 

[KALLT]

New macbook air user here. That's very technical for an operative system that should be user friendly. To me, it makes no sense and will live forever with this folder on the desktop not knowing if deleting it will make the system unreliable, will cause an explosion or any other damage. You know, it's an upgrade, do they expect the average user to technically operate on the system?

Just FYI, the folder on the desktop is just a link (“alias”) to the folder in the shared users directory (Macintosh HD → Users → Shared → Relocated Items). You can safely delete the link on the desktop without touching the actual folder, if you don’t want to delete the latter.

 

[Ritsuka]

Just delete it all, it has already been relocated, deleting I won't make any different to the system.

 

[Ghostrider72]

Just FYI, the folder on the desktop is just a link (“alias”) to the folder in the shared users directory (Macintosh HD → Users → Shared → Relocated Items). You can safely delete the link on the desktop without touching the actual folder, if you don’t want to delete the latter.

Thanks, I'll do it.

 

[Andyswr]

+1 with a German version.
but after all I prefer to live it or delate the folder because I prefer to wait for this to be solved by Apple because I´m not a developer and I think that this is a technical point

 

[port43]

If you edit system files, which I frequently do, and those files have replacements in new releases of MacOS, Apple will take the edited files and move them to to your desktop in the folder that everyone is experiencing. The idea being that you should compare what is in those files to the replacement files that Apple installed with the update. If the differences are something that you intended to keep, you can safely put those changes back in place to the default installed files.

In the case of "trustd", this was a group that Apple used for a process that validated certificates and identities on your system. There have been issues in the past with the daemon that used "trustd" becoming a runaway process that consumed resources and caused havoc with the system. It appears that Apple has reworked the way they will do validations and no longer need to use "trustd" in the same way. Otherwise they would not have created a backup on your desktop and that entry would still be in the /private/etc/group file.

It is safe to remove that folder from your desktop if the "trustd" line is the only difference shown.

 

[metabotschafter]

I decided to remove the alias and /shared/ copy of the new host file. Given the fact that only trustd is missing in the running config, which is compensated by the directory service and the fact that the trustd process is working, my assumption is that the OS will continue to handle things like before 11.3. As this issue seems to be wide spread, probably apple will silently replace the host file in a future update, when they are aware about it.

 

[TillichtoIllich]

I agree , but Bit of an academic question, but why should you [swap the files if] the fresh installed 11.3 os from VineRider does not include trustd as well. I am undecided so far.

VineReader said that on a new installation of macOS 11.3 /etc/group does contain that line. So it appears to be true what Apple states in the PDF file that I quoted above, that updating macOS to 11.3 does not overwrite the existing file, even though the default changed.

If you check the Directory Service, you will also see that the _trustd group exists and is correctly configured regardless whether it is mentioned in /etc/group:

% dscl . -read /Groups/_trustd
AppleMetaNodeLocation: /Local/Default
GeneratedUID: ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000011A
GroupMembers: FFFFEEEE-DDDD-CCCC-BBBB-AAAA0000011A
GroupMembership: _trustd
Password: *
PrimaryGroupID: 282
RealName: trustd
RecordName: _trustd
RecordType: dsRecTypeStandard:Groups

In other words, it is likely fine to do nothing (and hope that Apple resolved it somehow) or update /etc/group manually.

I have had over a dozen replicas of this desktop folder appear, one for every update since Mojave at least.
The typical culprit for me was master.passwd.system but this time I have been given a _default version of group.system as well.

The reason why you should swap the provided default in, and overwrite your local modified version, is that in my experience every update will continue to preserve your one modified line and park a fresh copy of the same Apple public service announcement (the folder we're all talking about) on your desktop.

It doesn't stop because it's not a bug, although I needed the instructions in this thread to finally know how to "compare and replace" them. I do consider it a bug that Apple's instructional PDF didn't print exactly what to do in the Terminal in both cases, because third option is to continue receiving this folder and not knowing how to stop it.

The only other information such a flowchart would need is to tell us that this isn't a case of accepting or rejecting changes, but of rolling back changes that Apple refrained from rolling back. I found the language confusing and unfortunately most users seem to agree.

Thank you very much, KALLT especially, for finally showing the necessary Terminal commands today! Glad that this new _default issue led me here!

 

[TillichtoIllich]

If you edit system files, which I frequently do, and those files have replacements in new releases of MacOS, Apple will take the edited files and move them to to your desktop in the folder that everyone is experiencing. The idea being that you should compare what is in those files to the replacement files that Apple installed with the update. If the differences are something that you intended to keep, you can safely put those changes back in place to the default installed files.

In the case of "trustd", this was a group that Apple used for a process that validated certificates and identities on your system. There have been issues in the past with the daemon that used "trustd" becoming a runaway process that consumed resources and caused havoc with the system. It appears that Apple has reworked the way they will do validations and no longer need to use "trustd" in the same way. Otherwise they would not have created a backup on your desktop and that entry would still be in the /private/etc/group file.

It is safe to remove that folder from your desktop if the "trustd" line is the only difference shown.

Just wanted to respond that, as I suggest just now in post 36, a person may have to remove the "provided Apple default version of file" folder from the desktop again and again for years if they allow the custom file to persist. An unusual annoyance even though safe. The problem is that until now, typical users have had no further instructions to indicate how to do the actual comparison nor where to perform a replacement (nor why).

 

[ralphthemagi]

I have had over a dozen replicas of this desktop folder appear, one for every update since Mojave at least.
The typical culprit for me was master.passwd.system but this time I have been given a _default version of group.system as well.

The reason why you should swap the provided default in, and overwrite your local modified version, is that in my experience every update will continue to preserve your one modified line and park a fresh copy of the same Apple public service announcement (the folder we're all talking about) on your desktop.

It doesn't stop because it's not a bug, although I needed the instructions in this thread to finally know how to "compare and replace" them. I do consider it a bug that Apple's instructional PDF didn't print exactly what to do in the Terminal in both cases, because third option is to continue receiving this folder and not knowing how to stop it.

The only other information such a flowchart would need is to tell us that this isn't a case of accepting or rejecting changes, but of rolling back changes that Apple refrained from rolling back. I found the language confusing and unfortunately most users seem to agree.

Thank you very much, KALLT especially, for finally showing the necessary Terminal commands today! Glad that this new _default issue led me here!

In this case it may well be a bug. It is quite possible this was either removed by Apple in a previous update OR is removed by another process (e.g. updating certificates, signing into iCloud for the first time, etc.).

I can easily envision a scenario where something like this is enabled in the default state but later removed.

It is a pretty trivial change in either case, but there is no reason to believe the the default state is the correct state, especially given what happened in November.

 

[TillichtoIllich]

I'll see if the next update is any different. Now that I have rolled back both files to the provided default, my theory is that I won't see a desktop Relocated Items folder appear again.

 

[metabotschafter]

It is a pretty trivial change in either case, but there is no reason to believe the the default state is the correct state, especially given what happened in November.

I think it is interesting that it is almost redundant. The trustd process is not affected anyway, so beside single user mode it is more like a „UNIX Legacy mode“ support to keep this file used by the OS.

 

[TillichtoIllich]

With 11.3.1 installation I no longer received an Apple desktop copy of group.system_default anymore. I think I would have if I hadn't done the swap written in post 11 of this thread.

 

[chris4565]

With 11.3.1 installation I no longer received an Apple desktop copy of group.system_default anymore. I think I would have if I hadn't done the swap written in post 11 of this thread.

Yup. I didn't do the swap manually and got this folder again on my desktop after the 11.3.1 update.

 

[metabotschafter]

Same here

 

[alexjohnson]

I see this is common. I have two M1s: a MacBook Air, where this does not happen, and a Mac mini, where is does. I did not use Migration Assistant so in theory there should be no cruft. But, I am running the Big Sur PBs and this happens with every update. I can follow what is above about 75%, but am a script kiddie on Terminal, at best. What I would like is to fix this. Obviously I know I can simply delete the Relocated Items folder; what I would like to know is:
- Can I delete the "new" file so that it stops being moved to a created Relocated Items; and
- Where is it located? I see Items/Configuration/private/etc/group.system_default /etc/group above; I can't find such a path even when I reveal hidden folders and files.

 

[metabotschafter]

Based on the latest update, if you delete it it will be recreated after the next macos update. If you like to get rid of it, KALLT´s approach is the way to go. So you need to replace your current group file in /private/etc/ with the group file in relocated folder.

 

[metabotschafter]

If you are certain that only that line (_trustd:*:282:_trustd) is different, you can simply swap the files:

sudo cp /etc/group /etc/group~previous
sudo mv /Users/Shared/Relocated\ Items/Configuration/private/etc/group.system_default /etc/group

that´s the way to go

 

[ghsDUDE]

I have the same issue...I was going to delete the shortcut from my desktop, but I understand that doesn't really delete anything.

Is it safe to go in and delete it? If so, do I just delete the Relocated Items (which also deletes Configuration > Private > Etc. > Group.System_Default

Or should I leave it alone?

 

[alexjohnson]

I have the same issue...I was going to delete the shortcut from my desktop, but I understand that doesn't really delete anything.

Is it safe to go in and delete it? If so, do I just delete the Relocated Items (which also deletes Configuration > Private > Etc. > Group.System_Default

Or should I leave it alone?

You can delete the file and folders the Desktop alias points to just fine: the whole point of that is that the OS has supposedly moved files to a place where they're not installed or loaded, but you still have them. In this case we are surmising that Apple has got it slightly wrong, and so it seems like it will be recreated with the next system update. I have tried the Terminal commands above and will see what happens with the next update.

Short version: you can nuke the alias, and the files and folder hierarchy it points to. But you might be better following KALLT's commands, and (hopefully) fixing it: and you can't do that if you've deleted the file.

 

[eduarcor]

Got it solved after the 11.4 update or still the same? I was about to update...

 

[alexjohnson]

Got it solved after the 11.4 update or still the same? I was about to update...

Since I followed KALLT 's commands, it has been fixed; now on 11.5 PB.