Cannot delete symlink from root

[EasyGoing1]

Hello,

I have an interesting problem.

I have a link file in the root of my boot drive called 'home' which is giving me grief and seemingly impossible to deal with. When I do an ls -l / it shows me this:

lrwxr-xr-x 1 root wheel 25 Oct 25 23:13 home -> /System/Volumes/Data/home

It should be noted that the drive /Volumes/Data is NOT mounted and is in fact disconnected physically from the computer. It is an external, 8TB drive.

When I issue this command, I get this response:

$rm -R home
rm: home: Read-only file system

I tried rebooting into recovery mode at which point I was able to see AND REMOVE home from the MacOS - Data volume (which is an APFS container and NOT the actual external drive called Data). However, when I reboot, the file still exists and I cannot delete it.

When I boot into single-user mode, I don't see the file, though I'm not sure I'm actually looking at the root of the same volume and I'm not quite sure how to know that I am looking at the same volume.

Any ideas on how to deal with this file or how to remove it?

Thank you,

Mike

 

[appltech]

Hi! Do you have an OS installed on that external drive or maybe it's a time machine backup?
If it's an external OS, it could be protected by it's own SIP that can be disabled if you really need to remove that link.

 

[EasyGoing1]

Hi! Do you have an OS installed on that external drive or maybe it's a time machine backup?
If it's an external OS, it could be protected by it's own SIP that can be disabled if you really need to remove that link.

Hi,

No, the external drive was always intended for just data ... I have a different drive for Time Machine and I've never installed an operating system on this external. I merely formatted it as a full 8TB APFS drive right out of the box and have been using it for almost a year now just storing personal data ... media files ... things like that.

 

[appltech]

If the topic is still relevant:
- symbolic links are pointers to original files, which should be on your external (and your external is not connected as i understand). What are you trying to do with that link, exactly : remove it (you can do that via terminal with "rm path/to/symlink") or tell it to point somewhere else?
- how did you create the link before : through terminal or via app like SymbolicLinker?

 

[EasyGoing1]

If the topic is still relevant:
- symbolic links are pointers to original files, which should be on your external (and your external is not connected as i understand). What are you trying to do with that link, exactly : remove it (you can do that via terminal with "rm path/to/symlink") or tell it to point somewhere else?
- how did you create the link before : through terminal or via app like SymbolicLinker?

The topic IS still relevant...

I'm very much aware of what symlinks are (I've been a network engineer since the last 1990s) In fact, I was sorely disappointed when Apple removed hard links which I rather liked using from time to time for various things. I like my symbolic links to appear as though they are the actual object they link to in a manner that appears no different than any other real object in a folder so that software can act on that linked object within the linked context ... but that got pulled years ago.

But I digress ...

This particular symbolic link that is at the root of my MBP boot volume was certainly NOT created by me so I'm not sure how it got there. I would never create a link in the root of any volume.

And here is what is interesting about this link. It appears to be a link to a folder on an external drive that DOES NOT EXIST anymore, and I don't remember ever having a folder on that external drive with the name Home ... but nonetheless, the link points to a folder on the root of that non-existent external drive called home.

When I double-click on the link in finder, it takes me to that place as though it actually exists ... though there are no files in it, I find it peculiar that Finder can actually navigate to it and I can cd into it inside Terminal.

Also, as I stated in my OP, I did try to remove the link from within terminal without success. Here is a screen shot that I just took showing that I can CD into the "folder" / symlink without any arguments from the file system, and then I go to the root and do an ls -l where you can see that it's a folder pointing to a non-existent location (/Volumes/Data DOES NOT EXIST) which I show by attempting to cd into that location. I colored my commands and the responses for contrast, making it easier to see the relevant information in the screenshot.

I have not tried an app like symbolic linker ... I'm wondering if /home is a folder that exists on every installation of MacOS and if somehow mine got corrupted...

 

[Analog Kid]

Note: the /home directory appears to be a standard directory, so remove it with caution!

Why the -R flag? The link isn't a directory, it links to a directory. Does a basic 'sudo rm /home' work?

I've also found that there are certain protected directories-- usually you get a message to that effect though when you try to access them. I've found that I can drag links around in Finder to a directory I'm allowed to operate in, then modify it there.

 

[Analog Kid]

I'm wondering if /home is a folder that exists on every installation of MacOS and if somehow mine got corrupted...

There does appear to be a standard symlink from /home to /System/Volumes/Data/home. On my machine, that directory exists, but is empty. It is a read only directory. Your 'rm -R home' command is trying to delete the file hierarchy at /System/Volumes/Data/home, which exists and is read only.

It looks like you are saying /Volumes/Data is not mounted, but this link is pointing to /System/Volumes/Data which is a different directory and not a removable drive.

 

[Analog Kid]

In fact, I was sorely disappointed when Apple removed hard links which I rather liked using from time to time for various things.

Apple did not remove hard links. From the ln man page:

"By default, ln makes hard links. A hard link to a file is indistinguishable from the original directory entry"​

 

[spainbran]

Maybe stupid but it seems like a linux link:
have you tried:
unlink /home
sudo unlink /home
?

 

[Honza1]

Do NOT remove this link, it is part of your OS.
If you look on your SSD container disk 1... in the current macOS, you have two volumes by default. System volume, mounted read only under normal conditions, with system. And then each user (I think?) has "...- Data" volume. this is where all the Applications and user data are - this is read-write. This is the new layout of system protecting the OS files.
This link is simply OS created link to homes for user on that SSD volume called "... - Data" where your data reside. On my mac is it called "Macintosh HD - Data". Look in Disk Utility.
The fact you have another external drive with name "Data" is inconsequential, this has nothing to do with your Data external drive.

 

[spainbran]

Never looked at it but I have it too:

home -> /System/Volumes/Data/home/

Why would know it all apple use the unix standards, while they invented: /Users

And I thought they were BSD compliant using their code and never paying for it.

I sapple side loading code when they need it?

 

[Darth.Titan]

Agree with @Honza1

Leave it alone. That symlink is supposed to be there. It has a purpose. It's present on all my Macs.

As a network engineer, this might be hard for you to hear, but stay out of the root of the system. Let the OS manage things at that level.

 

[spainbran]

so basically:
/System/Volumes/Data/home
points to
/Users/$User
which points to ...

But as a network engineer you consider it as normal and should be the standard and you recommend it.

Ok next time as a engineer myself, I will point:
1.1.1.1 to www.apple.com and recommended it as normal ...

There are standards, respect them for all the IT community sakes.

 

[svenmany]

Definitely give https://bombich.com/kb/ccc5/working-apfs-volume-groups a read. It discusses firmlinks.

 

[EasyGoing1]

Apple did not remove hard links. From the ln man page:

"By default, ln makes hard links. A hard link to a file is indistinguishable from the original directory entry"​

Well ... to be fair, the terminology has varied over the years, but the bottom line is you can't hard link drive objects like we used to be able to ... and I can't remember why they did it but you basically can't make a link to an object elsewhere in the file system and have it appear as though it is the actual object only in a different folder ... it's always going to show up as a link.

 

[EasyGoing1]

Agree with @Honza1

Leave it alone. That symlink is supposed to be there. It has a purpose. It's present on all my Macs.

As a network engineer, this might be hard for you to hear, but stay out of the root of the system. Let the OS manage things at that level.

My bad I thought this was written to me ... I'm tired... been a long day. I responded then edited ... don't see a way to remove it...

 

[EasyGoing1]

There does appear to be a standard symlink from /home to /System/Volumes/Data/home. On my machine, that directory exists, but is empty. It is a read only directory. Your 'rm -R home' command is trying to delete the file hierarchy at /System/Volumes/Data/home, which exists and is read only.

It looks like you are saying /Volumes/Data is not mounted, but this link is pointing to /System/Volumes/Data which is a different directory and not a removable drive.

You're absolutely right ... how in the hell did I miss that? wow... I think I just saw Volumes/Data and since that's been the location of my external data drive forever ... I just zero'd in on that part of the path ... damn... nice catch.

And so it seems that I have seen a problem where none exists because I have had a /Volumes/Data folder for years up until recently... this might be the most useless post Ive ever made. ☺

 

[Analog Kid]

You're absolutely right ... how in the hell did I miss that? wow... I think I just saw Volumes/Data and since that's been the location of my external data drive forever ... I just zero'd in on that part of the path ... damn... nice catch.

And so it seems that I have seen a problem where none exists because I have had a /Volumes/Data folder for years up until recently... this might be the most useless post Ive ever made. ☺

No worries. At least we figured it out before you found a way to delete it!

 

[EasyGoing1]

Apple did not remove hard links. From the ln man page:

"By default, ln makes hard links. A hard link to a file is indistinguishable from the original directory entry"​

Just to be thorough on this topic ... here are some discussions where clearly other people are talking about apple nerfing the ln command ... and I specifically remember this being an issue for me in the mid 2000's - ish... here are some links where Apples change to the ln command are specifically mentioned:

What is the Bash command to create a hardlink to a directory in OS X?

How do you create a hardlink (as opposed to a symlink or a Mac OS alias) in OS X that points to a directory? There is the command "ln target destination" but that only works when the target is a fi...

serverfault.com

and this one ...

Creating directory hard links in Mac OS X

How can I create a hard link to a directory in Mac OS X? This feature has been added to their file system in Mac OS X v10.5 (Leopard) (for time machine), but I could not f...

stackoverflow.com

 

[EasyGoing1]

No worries. At least we figured it out before you found a way to delete it!

YES ... you have saved me from myself ... and I am VERY grateful ... I was getting ready to drop into recovery mode and see if I could wedge it lose and throw it in the trash.

 

[EasyGoing1]

Definitely give https://bombich.com/kb/ccc5/working-apfs-volume-groups a read. It discusses firmlinks.

This was a good read and filled in some gaps in my knowledge concerning APFS. I've been recently learning about ZFS and it seems there are a lot of similarities between the two file systems.

Thank you for posting the link.

 

[Analog Kid]

Just to be thorough on this topic ... here are some discussions where clearly other people are talking about apple nerfing the ln command ... and I specifically remember this being an issue for me in the mid 2000's - ish... here are some links where Apples change to the ln command are specifically mentioned:

What is the Bash command to create a hardlink to a directory in OS X?

How do you create a hardlink (as opposed to a symlink or a Mac OS alias) in OS X that points to a directory? There is the command "ln target destination" but that only works when the target is a fi...

serverfault.com

and this one ...

Creating directory hard links in Mac OS X

How can I create a hard link to a directory in Mac OS X? This feature has been added to their file system in Mac OS X v10.5 (Leopard) (for time machine), but I could not f...

stackoverflow.com

View attachment 1908493

I think whoever made that comment got it wrong. I'm pretty sure no modern unix variant allows general hardlinks to directories. In some flavors you can try to force it with flags, but I'm not sure it works much better than pushing the walk button at a busy intersection.

Why are hard links to directories not allowed in UNIX/Linux?

I read in text books that Unix/Linux doesn't allow hard links to directories but does allow soft links. Is it because, when we have cycles and if we create hard links, and after some time we delete...

unix.stackexchange.com

What Apple did when they introduced TimeMachine is reintroduced directory hard links (that's how incremental backups are done) but only TimeMachine gets to use them. I've seen people write their own custom linkers using the link() system call, but...

Porn Folder

xkcd.com

 

[svenmany]

I was wondering what you all think of my intuition that firmlinks are kind of like hard links between directories. For example

/System/Library/Caches is the same as /System/Volumes/Data/System/Library/Caches

Not really hard links since they are actually on two different volumes. These "Caches" directories have a "sunlnk" flag on them.

 

[spainbran]

Apple tries to reinvent the wheel and pretend they are the owners/inventors.
I'm afraid they want to turn mac os tho what IOS is, a closed system.

 

[Analog Kid]

I was wondering what you all think of my intuition that firmlinks are kind of like hard links between directories. For example

/System/Library/Caches is the same as /System/Volumes/Data/System/Library/Caches

Not really hard links since they are actually on two different volumes. These "Caches" directories have a "sunlnk" flag on them.

I’m not a file system expert by any stretch, and I know there are people here who are so maybe they’ll weigh in, but from the limited documentation I can find a firmlink looks less like a hardlink and more like a symlink with path traversal history.

A key feature of a hardlink is that it anchors a file’s data to the directory structure in two or more places. You can delete either reference to the file’s inode but the content will remain linked into the file system until you delete all of those references.

With a symlink, there’s only one anchor to the data and the symlink is basically a redirect to the original file by name. When you traverse a symlink to a directory and then back out, you’ll follow the hard path not the symbolic one.

This is part of what makes hardlinks to directories so treacherous. When you follow a hard link into a directory and then back out, which path do you follow? There are two hard paths out, both with equal standing, and both stateless.

A firmlink looks like a symlink that when you follow a path and then back out it follows the link in reverse, not the hard path. It makes the links between directores more transparent. It does not appear to include the key feature of a hard link though, being that there is only one anchor for the contents into the filesystem. If a firmlink is created to another path (and firmlinks are only permitted to directories), and then the original path is deleted, the content does not remain linked to the file system by the firmlink.

I don’t see any way for users to create firmlinks. The purpose is just to be able to make separate read only and read/write volumes appear as one unified directory structure to prevent malicious changes to the file system while retaining something close to a standard unix file tree.