A common error with Time Machine is that it claims its image to be read-only.
This applies only if your Time Machine is stored on a remote system, such as a Time Capsule, another Mac or some SMB server.
If you restore a different computer from you Backup, during the restore, the Time Machine volume becomes read-only (luckily enough). However, turning write access back on may fail.
This issue is difficult to debug.
First, attach the disk image and run a file system check:
Take note of the disk number, e.g. disk1, as we need it in the next command:
1
admin@MyMac ~@ fsck_hfs -f /dev/disk1
If this is successful, you may now mount the image to check if that helped, but in my case it had not helped at all.
Here’s the comparison with a fresh (empty) disk image created by Time Machine after I had removed the original out of the way. The original is Backup of MyMac and the fresh one is Backup of MyMac 1:
admin@MyMac ~$ ls -le /Volumes/Backup\ of\ MyMac*
/Volumes/Backup of MyMac:
total 0
drwxr-xr-x+ 3 root staff 102 Mar 10 14:09 Backups.backupdb
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
/Volumes/Backup of MyMac 1:
total 0
drwxr-xr-x+ 3 root staff 102 Mar 15 15:16 Backups.backupdb
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
admin@MyMac ~$ mount |grep /Volumes/Backup
/dev/disk1s2 on /Volumes/Backup of MyMac (hfs, local, nodev, nosuid, journaled, mounted by admin)/dev/disk2s2 on /Volumes/Backup of MyMac 1 (hfs, local, nodev, nosuid, journaled, mounted by admin)admin@MyMac ~$ diskutil list
[...]/dev/disk1
#: TYPE NAME SIZE IDENTIFIER 0: Apple_partition_scheme *698.3 Gi disk1
1: Apple_partition_map 31.5 Ki disk1s1
2: Apple_HFSX Backup of MyMac 698.3 Gi disk1s2
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER 0: Apple_partition_scheme *698.3 Gi disk2
1: Apple_partition_map 31.5 Ki disk2s1
2: Apple_HFSX Backup of MyMac 698.3 Gi disk2s2
admin@MyMac ~$ diskutil info /dev/disk1
Device Identifier: disk1
Device Node: /dev/disk1
Part Of Whole: disk1
Device / Media Name: Apple sparse bundle disk image Media
Volume Name:
Mount Point:
Partition Type: Apple_partition_scheme
Bootable: Not bootable
Media Type: Generic
Protocol: Disk Image
SMART Status: Not Supported
Total Size: 698.3 Gi (749812383744 B)(1464477312 512-byte blocks) Free Space: 0.0 B (0 B)(0 512-byte blocks) Read Only: No
Ejectable: Yes
Whole: Yes
Internal: No
OS 9 Drivers: No
Low Level Format: Not Supported
admin@MyMac ~$ diskutil info /dev/disk2
Device Identifier: disk2
Device Node: /dev/disk2
Part Of Whole: disk2
Device / Media Name: Apple sparse bundle disk image Media
Volume Name:
Mount Point:
Partition Type: Apple_partition_scheme
Bootable: Not bootable
Media Type: Generic
Protocol: Disk Image
SMART Status: Not Supported
Total Size: 698.3 Gi (749812383744 B)(1464477312 512-byte blocks) Free Space: 0.0 B (0 B)(0 512-byte blocks) Read Only: No
Ejectable: Yes
Whole: Yes
Internal: No
OS 9 Drivers: No
Low Level Format: Not Supported
So there obviously is zero difference, but still one is writable while the other is not. What worked in my case is to chown the directory in /Volumes to my username:
1234567891011
admin@MyMac ~$ sudo chown admin /Volumes/Backup\ of\ MyMac
admin@MyMac ~$ ls -le /Volumes/Backup\ of\ MyMac*
/Volumes/Backup of MyMac:
total 0
drwxr-xr-x+ 3 root staff 102 Mar 10 14:09 Backups.backupdb
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
/Volumes/Backup of MyMac 1:
total 0
drwxr-xr-x+ 3 root staff 102 Mar 15 15:16 Backups.backupdb
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
Again, nothing has changed, but from now on, the volume is writable :-)