The folder "System" can't be moved into one of its subfolders. ***WTH?***

[eppur_se_muova]

A couple of years ago, I picked up a used iMac at auction for very little $$$. It came with a 650GB Fusion drive which I modified to have four partitions, only one of which boots. I deleted unwanted files from the boot partition, changed passwords etc., but didn't reformat that partition. Later I upgraded the OS with the OpenCore patcher to 10.15.7 aka Catalina. I've been using it with few problems until now. This is the first disk I've had that was already partitioned as APFS when I got it, and I'm seeing strange behavior I've not encountered before.

I tried installing two different Linuces on one of the other partitions, and neither could see the APFS partitions. When booting into OSX (from an APFS partition) I couldn't see the Linux partition(s) either ! This makes data transfer a little difficult. (APFS has been out for quite a while -- why can't it be read by other OS's ?? And why can't OSX read older formats for backwards compatibility ? This seems like burning bridges in a serious, totally non-advantageous way.)

I've backed up OSX with TimeMachine so I can do some serious disk cleanup without losing files to accidents.

I copied all the folders -- Applications, Library, Users -- from the OSX boot partition to a partition on an external USB SSD and then tried copying the System folder over. These are two *different* partitions on two *different* storage devices, both of which I am the owner. I should be able to move or copy any files I want to, maybe with a request for password. Instead I get the baffling message in the title:

The folder “System” can’t be moved into one of its subfolders.

The same thing happened when I tried to copy it onto a thumb drive (exFAT formatted).

How can a separate disk AND partition involve a subfolder of the folder being copied ?? Is there a workaround that doesn't involve reformatting everything first ??

[canetoad]

1. This excerpt may explain WHY

https://en.wikipedia.org/wiki/Apple_File_System

Partition scheme

APFS uses the GPT partition scheme. Within the GPT scheme are one or more APFS containers (partition type GUID is 7C3457EF-0000-11AA-AA11-00306543ECAC). Within each container there are one or more APFS volumes, all of which share the allocated space of the container, and each volume may have APFS volume roles. macOS Catalina (macOS 10.15) introduced the APFS volume group, which are groups of volumes that Finder displays as one volume. APFS firmlinks lie between hard links and soft links, and link between volumes.

In macOS Catalina the System volume role (usually named "Macintosh HD&quot became read-only, and in macOS Big Sur (macOS 11) it became a signed system volume (SSV) and only volume snapshots are mounted. The Data volume role (usually named "Macintosh HD - Data&quot is used as an overlay or shadow of the System volume, and both the System and Data volumes are part of the same volume group and shown as one in Finder.

Can't offer any more than this - last mac was around the turn of century!

[The Wizard]

2. Above my paygrade.

[LastDemocratInSC]

3. Can a parent folder be moved into one of its own sub-folders?

[Tasmanian Devil]

4. Fun with Lunix & macOS & boot volumes

Once upon a time you could simply copy macOS files around to build boot volumes. Then you needed to be careful to copy the folders then run bless(1) to appropriately set up boot blocks. Then Apple kept adding more and more security features so that malware even running with root privs couldn't touch system files (google SIP and see man csrutil). And with all the extended file attributes ... it's a mess to try and build a bootable volume by hand.

There used to be Carbon Copy Cloner that would help build boot volumes, but a quick google leads me to think it's not terribly robust anymore.

Bottom line: to build a bootable volume, boot into recovery mode and use the disk utility app in the recovery environment to reformat and build your boot volumes. It's been a while since I've done this but you used to be able to tell it to erase and install an OS in specific partitions. It wasn't fast (it can download the OS over a network connection I think), but it worked.

On macOS, to read linux filesystems, check out https://github.com/nohajc/anylinuxfs

In Linux .. it needs extra help to read APFS filesystems. But if you've formatted for HFS+ it should have native support and should be able to be just mounted.

Ofc just using ex-FAT to move files between the two usually works ok. (disclaimer: mac files can have extended attributes that don't copy well with MSDOS filesystems).

Oh yeah why your copy failed: there's probably a symlink in System that points back to a parent directory so when you use a simple utility to try and copy ... it tries to follow the link and make a copy of System inside System and boom. I remember Xcode.app having this problem, causing simple ditto's or cp -R to never finish. TBD if the latest (gnu)tar or cpio is any better.

HTH, but I'm not exactly sure what your goals are ... and dealing with modern macOS filesystems in non-standard ways has more than a few gotchas!

[eppur_se_muova]

5. Thanks. I'm at a loss as to what Apple is trying to do here. I get there are security issues, but ...

when a partition on a separate device can't be used for drag-and-drop file transfers, someone, somewhere, screwed up big time.

All the files I really need are in the Users folder, so I copied it to LinuxLite and am now converting my iMac to a Linux box. I knew I would have to do this eventually, but I'm being careful not to leave anything behind.

Not sure when to actually nuke the APFS partition; I'll probably save it just in case. Meanwhile everything is backed up w/TimeMachine, so I can move files to other OSX boxes.



Thanks for your comments. Not sure how useful they are yet, I need to mull things over.

[Tasmanian Devil]

6. Drag & Drop

Drag and drop of most files works fine. As long as they are simple files and folders. Where simple means no resource fork (data only), no extended attributes, no setuid bits, no worries about unix file or group ownerships, file names are unique (not case-sensitive), names are not too long, names don't contain special characters, no extended attributes, no symbolic links, no hard links, no sparse files ... etc. etc!

The focus has been to be able to copy normal user files. Using drag & drop to copy system files has always been tricky, as many of those files have special modes (e.g. setuid root), or are locked down or even invisible to try and prevent accidental modification by users. E.g. the ~/Library folders have been hidden by default since the first days of OS-X.

I'll agree that it's silly difficult to copy the OS to a different volume, but it's not something the average mac user has much interest in doing.