Acl mac os x

nelstrom / access-control-lists-on-osx.md

I have two user accounts set up on my mac. User drew I use for most things, but if I’m making a screencast I’ll switch to the demo user. I know that the demo user has a clean desktop, and the font size is larger than usual in my terminal and text editors, making everything a bit more legible when capturing the screen. When I record a screencast as the demo user, I save the file to /Users/Shared/screencasts . As I understand it, the /Users/Shared directory is supposed to be accessible to all user accounts on the mac. If I created and saved a screenflow document as the demo user, I should be able to read and write that file when logged in as user drew .

That was the theory, but it didn’t always work out that well in practice. I would occasionally find that a directory was only writable by one user or the other. Perhaps I’d open a screenflow document as user drew and attempt to export the video to the same directory, only to find that the directory was owned by demo , meaning that I couldn’t create new files in that directory when logged in as user drew .

Ideally, I’d like to be able to set the permissions on the /Users/Shared/screencasts directory, and have all files and directories created beneath it inherit those permissions. This seems to have done the trick:

In the first command, the owner is set to demo and the group is set to staff for the screencasts directory, as well as all files and subdirectories contained below it. Both demo and drew users are already in the staff group. If I can make it so that the staff group has read, write, and execute (where apt) rights for all files/directories, then I’ll have what I need.

The second command assigns an access control list (ACL) for the staff group on the screencasts directory (and all of its children). I’ve included a lot of flags, but the ones to note are file_inherit and directory_inherit . If I create a file or directory inside of the screencasts directory, then it will inherit the same ACL flags.

To inspect the ACL, you can run the ls command with the -e flag. For example:

As well as seeing the usual line of info about each listing, there’s an extra row giving details about the ACL. The screencasts directory has r-x mode set for the group, so you might think that users in the staff group would be unable to add files and directories to the screencasts directory. But the ACL includes the flags: add_file and add_subdirectory , which means that users in the staff group can do those things.

I could demonstrate as user drew :

The directory foo and the file bar are both owned by user drew , but they’re assigned to the group staff . And since the demo user is in the group staff , it gets all of the privileges listed in the ACL.

Источник

Bit Wrangling

A meandering discourse on binary coercion

Access control lists on Mac OS X 10.4

Why use access control lists?
Access Control Lists (ACLs) were devised to replace the traditional POSIX permissions system which, by comparison, is fairly limited. The traditional POSIX system uses only 9 bits of data per file system object to define permissions (excluding the sticky bit and the set UID and set GID bits). The system is such that each file system object has three sets (technically classes) of permissions, applying to the 1) file’s owner, 2) the file’s owning group and 3) “everyone else” (by convention, the permissions are always displayed in that order). For each of these permission sets, the ability to read, write and/or execute may be set.

For example, a file with permissions rw−r−−r−− can be read and written by the owner (rw−), but only read by everyone else (r−−), whereas a file with permissions rwxr−x−−− can be read, written and executed by the owner (rwx), read and executed by other group members (r−x), but not accessed at all by other users (−−−). Such permissions are often expressed in 3 digit octal values where each digit represents a permission set (owner, group and other, in that order) and the number is calculated by adding 4 if the read bit is set, 2 if the write bit is set and 1 if the execute bit is set. So, for example, rwxr-xr-x would be represented by 755 in octal (4+2+1, 4+1, 4+1) and rwxr−−−−− would be represented by 740 in octal (4+2+1, 4, 0). More information on how POSIX permissions are implemented on OS X can be found here and here.

This system has been in place for many years on UNIX and is, considering its simplicity, quite powerful. However, in many situations, “workarounds” are necessary to achieve the desired result. For example, although a user can belong to more than one group (see the id command, specifically, id -Gn [username] ), a file may only have one owner and one group assigned to it. Therefore, in the situation where two (or more) groups require access to a file, a new “quasi-group” must be created containing all members from both groups, and ownership of the file must be transferred to the new group using chgrp quasigroup foo.bar . This is clearly less than ideal as the new group doesn’t (necessarily) reflect an actual organisational unit, which is what the group attribute was originally designed to do. ACLs were introduced in order to overcome such limitations as well as provide much finer-grained control over file and directory permissions.

What are access control lists?
Apple implemented kernel-level support for ACLs in Mac OS X 10.4 “Tiger” to supplement the POSIX permission system. Apple’s implementation of ACLs is compatible with IEEE POSIX.1e draft 17 (2.0 MB gzipped PDF) which, despite being withdrawn by the IEEE, has been widely implemented and, although not an official standard, ACLs implemented to this draft standard are commonly referred to as “POSIX ACLs.” Apple’s ACL implementation is also compatible with that in Windows Server 2003 and Windows XP. However, not all file systems supported by Mac OS X support ACLs; only HFS+ supports them locally, while AFP and SMB/CIFS support ACLs over the network.

An ACL (which is always associated with a file system object by means of an extended attribute in HFS+) consists of a list of permissions in the form of so-called access control entries (ACEs). In turn, an ACE contains a set of permissions, whether those permissions are allowed or denied, the ID of the “trustee” to which the these permissions apply and rules of inheritance for the permissions. A trustee in this context may be either a user or a group. Note that under the ACL permission scheme, its possible for a group to be the owner of a file — a feat that is not possible under the POSIX system. Also, POSIX makes no provision for inheritance of permissions. While possible to recursively apply permissions to all subdirectories and enclosed items, it is, in Apple’s words, a “one-time operation”, i.e. any newly created files or folders in that file system branch would be created with the default permissions. Here’s a (simplified) view of exactly what’s contained in an ACL:

The granularity of control over file access is considerably greater with ACLs than with the POSIX system, as the following table of ACL access rights demonstrates (courtesy of the chmod man page and sys/acl.h):

Bit name	Description
All file system objects:
delete (ACL_DELETE)	Delete the item. Deletion may be granted by either this permission on an object or the delete_child right on the containing directory.
readattr (ACL_READ_ATTRIBUTES)	Read an objects basic attributes. This is implicitly granted if the object can be looked up and not explicitly denied.
writeattr (ACL_WRITE_ATTRIBUTES)	Write an object’s basic attributes.
readextattr (ACL_READ_EXTATTRIBUTES)	Read extended attributes.
writeextattr (ACL_WRITE_EXTATTRIBUTES)	Write extended attributes.
readsecurity (ACL_READ_SECURITY)	Read an object’s extended security information (ACL).
writesecurity (ACL_WRITE_SECURITY)	Write an object’s security information (ownership, mode, ACL).
chown (ACL_CHANGE_OWNER)	Change an object’s ownership.
Directories only:
list (ACL_LIST_DIRECTORY)	List entries.
search (ACL_SEARCH)	Look up files by name.
add_file (ACL_ADD_FILE)	Add a file.
add_subdirectory (ACL_ADD_SUBDIRECTORY)	Add a subdirectory.
delete_child (ACL_DELETE_CHILD)	Delete a contained object. See the file delete permission above.
Non-directory file system objects only:
read (ACL_READ_DATA)	Open for reading.
write (ACL_WRITE_DATA)	Open for writing.
append (ACL_APPEND_DATA)	Open for writing, but in a fashion that only allows writes into areas of the file not previously written.
execute (ACL_EXECUTE)	Execute the file as a script or program.

Activating and using access control lists on Mac OS X
It’s worth noting at this point that ACLs are in fact switched off by default in Mac OS X. In order to enable them, the fsaclctl program must be used as follows: sudo fsaclctl -p /mountpoint -e , obviously substituting in the appropriate mount point of the volume of interest. ACLs can be activated on all relevant volumes by issuing the command $sudo fsaclctl -a -e and similarly disabled by $sudo fsaclctl -a -d . Finally, the ACL status of a disk can be obtained by simply running sudo fsaclctl -p /mountpoint .

If ACLs have been enabled on the startup volume, a reboot ( sudo shutdown -r now ) of the system is required such that the change is registered by all applications. If the volume is not the startup disk, simply remounting the file system will suffice.

Once ACLs are activated, the tools used to read and modify them vary between the client and server versions of Mac OS X. On Mac OS X client (as of 10.4.8), there is no graphical interface for manipulating ACLs anywhere to be found and, as such, reading and writing permissions to ACLs must be accomplished through the command line programs ls and chmod , respectively. In Mac OS X Server, the Workgroup manager has been updated to include a rather nifty GUI for viewing or altering ACLs:

I think the GUI’s fairly self-explanatory, but what about on Mac OS X client? ls supports printing of all ACEs associated with a file by specifying the -e flag, which must be used in conjunction with the -l in order to see the list of ACEs. Actually setting and changing ACLs is a little more complicated (although not greatly so) and makes use of the chmod command, which is the tool originally designed for changing standard POSIX permissions. chmod ‘s options for dealing with ACLs are: +a(#), -a, =a#, -E, -C, -i and -I . Here’s an example using chmod and ls -le to make a directory unsearchable to the “username” user:

$ mkdir nosearch
$ echo “Hello world” > nosearch/hideandseek.txt
$ ls -le
drwxr-xr-x 2 username group 68 Jan 12 14:28 nosearch
$ mdfind hideandseek.txt
/nosearch/hideandseek.txt
$ chmod +a “username deny search” nosearch
$ ls -le
$ drwxr-xr-x + 3 username group 102 Jan 12 14:36 nosearch
0: user:username deny search
$ mdfind hideandseek.txt
$

The most important command here is $ chmod +a “username deny search” nosearch , which shows the general syntax that must be used with chmod . Logically enough, to remove the same permission, one would have to type $ chmod –a “username deny search” nosearch (notice the minus rather than plus before the a.) Access control entries can also be inserted at a specified point in the list by using the +a# flag thus: $ chmod +a# 2 “others deny read” filename to insert the others deny read ACE at position 2 in the ACL. Ordering ACLs isn’t crucial, but the canonical order is something along these lines: user deny, user allow, group deny and group allow. The man pages for ls and chmod have very detailed information on all of the options available in each tool.

One glaring question remains — how do access control lists and POSIX permissions work in an interoperable fashion on OS X? Basically, if ACLs are active on the file system hosting the requested file, OS X will look for the existence of an ACL for that file. If an ACL is found, the kernel evaluates it ACE by ACE until the requested permission is either allowed or denied. If the requested permission is neither allowed or denied or if an ACL is not found, the system falls back to the POSIX permissions system and evaluates those. A very thorough description of permission evaluation on OS X can be found here.

Summary
With the introduction of access control lists, Apple was really playing catch-up with other operating system vendors (notably Microsoft). But catch-up they certainly did – the ACL implementation on OS X is very thorough and, as Apple says, is “not bolted-on” but rather integrated from kernel level upwards, as one would hope. Although there is still no graphical interface for managing ACLs on OS X client, the need for ACLs on a single- (or few-) user system is considerably smaller than on a server and the addition of a UI would probably only add unnecessary confusion to the client OS. The importance of the introduction on OS X Server, however, cannot be underestimated even if only for the fact that OS groups and users may finally represent the actual organisation of groups and users in real life. This, along with the removal of the POSIX 16-group membership limit, the ability for permissions to be automatically inherited and the much finer-grained access control makes ACLs an extremely attractive option for system administrators.

Источник

Apple Mac и причудливые устройства. LTO, SAS, Fibre Channel, eSATA

Темой настоящей статьи является подключение к Маку внешних устройств по интерфейсам SAS, Fibre Channel (FC), eSATA. Сразу оговоримся, что для решения задачи доступа к таким устройствам существует путь здорового человека: собрать дешёвый PC, воткнуть туда карту контроллера HBA SAS или FC (например, простейший адаптер LSI), подключить к этому контроллеру свои устройства, установить на PC любой линукс и работать с Мака через сеть. Но это банально и неинтересно. Мы пойдём путём хардкора и будем подключать свои устройства непосредственно к Маку.

Что нам для этого понадобится:
– приличное количество денежных средств для покупки новой аппаратуры, либо удача в аукционах на eBay (где, приложив чуть-чуть усилий, можно купить требуемую аппаратуру предыдущих поколений раз в 10 дешевле, чем по прайс-листу);
– эта статья.

Чтобы работать с магнитной лентой (в настоящее время почти повсеместно представленной форматом LTO), необходимо иметь ленточный накопитель (стример) или ленточную библиотеку стандарта LTO. Это довольно дорогое устройство при первичной покупке (от сотен тысяч рублей), но стоящее вменяемых денег при покупке б/у. Поскольку поколения LTO меняются примерно каждые два года, а совместимость ограничена двумя поколениями, то вторичный рынок в достаточной степени насыщен работоспособными устройствами четырёхлетней и более давности, т.е. позапрошлого и далее поколения. Если вы покупаете новое устройство для коммерческих целей, то сами понимаете зачем оно вам нужно. Если хотите купить для дома и семьи, то можете рассмотреть этот вариант, как способ архивирования информации (поскольку сами носители очень дёшевы в расчёте на 1 гигабайт).

Начиная с поколения LTO-5 (и отчасти LTO-4), устройства для работы с магнитной лентой аппаратно подключаются к компьютеру по интерфейсу SAS либо FC (обычно существует два варианта исполнения каждого устройства)

С другой стороны, фирма Apple любезно предоставляет нам в нашем Маке интерфейс USB-C (работающий по протоколам USB, Thunderbolt 3 либо DisplayPort), иногда интерфейс Ethernet, а также фирменные адаптеры Thunderbolt 3 – Thunderbolt 2 и Thunderbolt – FireWire 800.

Безвыходное положение? Не совсем. К счастью, шина Thunderbolt может работать в режиме PCIe и обеспечивать возможность подключения карт PCIe таким же образом, как если бы они были установлены непосредственно внутрь корпуса компьютера. За счёт этого возможны любые расширения аппаратной конфигурации Мака, был бы соответствующий адаптер и драйверы.

Концептуально простейшим способом решения задачи является внешний бокс для адаптеров PCIe с интерфейсом Thunderbolt (PCIe card expansion system), в который можно установить контроллер (Host bus adapter, HBA) SAS либо FC. Например, такие боксы выпускает фирма Sonnet и некоторые другие. Тут есть нюанс: нам подойдёт далеко не каждый контроллер, а только имеющий драйвер под macOS. Таких плат вообще немного, и самые дешёвые и популярные (например, те же LSI) в их число не входят. К счастью, фирма Sonnet дала себе труд составить таблицу совместимости карт PCIe с различными ОС через интерфейс Thunderbolt.

Другой способ решения – приобретение готового конвертера интерфейса Thunderbolt – SAS либо Thunderbolt – FC, который, по сути, представляет собой уже готовую сборку из бокса и контроллера. Наиболее известна на данном направлении фирма ATTO, но встречаются и изделия других фирм.

Заметим, что не все контроллеры SAS и FC аттестованы на соответствие стандарту LTO, так как это само по себе стоит денег. Некоторые производители прямо пишут, что работа их контроллеров с ленточными накопителями не предусмотрена.

Для полноты картины отметим, что фирма mLogic выпускает устройство, представляющее собой накопитель IBM LTO-8 во внешнем корпусе, в который сразу же интегрирован конвертер SAS в Thunderbolt 3. Это, однако, вещь ещё более экзотичная, чем всё вышеописанное, особенно по меркам наших краёв. Сомневаюсь, что это устройство можно даже легально ввезти в Россию (накопители LTO содержат криптографические средства, и производители, такие как IBM и HP, по этой причине получают на каждую модель разрешение ФСБ на импорт).

Далее мы рассмотрим для примера конкретный комплект оборудования, владельцем которого автор стал в результате нескольких удачных приобретений, но общий принцип должен сохраняться для всех вариантов.

Итак у нас имеется для работы с лентой следующее оборудование:
– компьютер Apple Mac mini 2018 с macOS 10.15 Catalina, имеющий порты USB-C с поддержкой Thunderbolt 3;
– адаптер Apple Thunderbolt 3 / Thunderbolt 2;
– кабель Apple Thunderbolt 2;
– конвертер интерфейса ATTO ThunderLink SH 1068 (2*Thunderbolt / 2*SAS-2);
– кабель SAS SFF-8088 – SFF-8088;
– ленточный накопитель LTO-5 IBM TS2350;
– картриджи LTO-5, чистящий картридж.

Теперь, как говорится, со всей этой фигнёй мы попытаемся взлететь.

Скачиваем с сайта ATTO последнюю версию драйвера ThunderLink SH 1068 (видимо, для нашего удобства он объединён с драйвером SH 2068 и находится в разделе 2068, о чём написано только внутри самого архива с драйвером) и конфигурационной утилиты ATTO.

Драйвер, естественно, нуждается в инсталляции. Перед подобными действиями автор советует всегда делать снапшот файловой системы APFS загрузочного диска командой

либо резевную копию загрузочного диска, если там HFS+. Мало ли что. Потом из снапшота будет легко откатиться.

Далее неискушённый, но проявляющий должную осмотрительность, ум, несомненно, склонится к тому, чтобы внимательно прочитать инструкцию ATTO по инсталляции драйвера и выполнить её. В результате – тадам! – получаем операционную систему, виснущую на этапе загрузки. Тут нам может пригодиться снапшот, из которого можно восстановиться, вызвав Time machine с раздела восстановления, или же с того же раздела восстановления можно вручную стереть болезный kext из каталога расширений ядра (автор в общем случае не рекомендует так делать).

Почему так происходит? Потому что о нас позаботилась фирма Apple. В последних версиях macOS нельзя так просто взять и внедрить посторонний код в процесс загрузки. Добрые программисты Apple заблокировали подобное деструктивное поведение. Точнее, заблокировали наполовину, когда ожидание драйвера внедряется, а сам драйвер нет, поэтому всё просто зависает.

Что должен делать искушённый ум перед инсталляцией драйвера? Во-первых, дать команду:

Если в ответ на неё мы получаем:

System Integrity Protection status: enabled.

то это означает, что добрые программисты Apple заботятся о нас, поэтому ничего у нас не выйдет, пока мы не отключим их замечательную защиту. Для этого перезагружаемся в раздел восстановления (⌘R), вызываем терминал и даём команду:

После этого перезагружаемся в рабочую систему, и уже тогда инсталлируем драйвер, а заодно и конфигурационную утилиту ATTO (в принципе, конфигурационная утилита нужна только для диагностики и не требуется при нормальной работе). По ходу дела, когда попросят, подтверждаем в системных настройках авторизацию фирмы ATTO. После инсталляции можно опять перезагрузиться в раздел восстановления и дать команду

В Apple снова о нас заботятся.

Теперь у нас есть поддержанный драйвером интерфейс к внешним устройствам SAS (либо FС, если бы использовался конвертер FC). Но как работать с лентой на логическом уровне?

Как известно неискушённому, но эрудированному, уму, любая Unix-совместимая система поддерживает ленточные накопители на уровне ядра и основных системных утилит, к которым, прежде всего, относятся mt (управление лентопротяжкой) и tar (архиватор, имеющий поддержку работы с архивами на ленте). Однако, что уточнит на это искушённый ум? Любая Unix-совместимая система, кроме macOS. Фирма Apple побеспокоилась о нас, изъяв поддержку ленточных устройств из своего кода.

Но неужели нельзя вернуть этот код, портировав стандартные опенсоурсные утилиты Unix в macOS? Хорошая новость состоит в том, что это уже сделала фирма Tolis (ссылку на которую я не привожу) в своём продукте Tolis Tape Tools. Плохая новость состоит в том, что пользование результатами своей работы упомянутая фирма оценивает в 399 долларов США. Оценки этого факта могут быть разными, но лично автор не готов к тому, чтобы платить кому-то 400 баксов за код, по большей части написанный совсем другими людьми и находящийся в открытом пользовании с 1970-х годов, а поэтому данный вопрос автор для себя считает закрытым. (Между прочим, на гитхабе есть заброшенный в смутном состоянии свободный проект IOSCSITape на эту же тему).

К счастью, в мире существует корпорация IBM, коммерческие аппетиты которой имеют совершенно другие масштабы, и потому не проявляются во всякой мелочёвке.

Того же самого, что делают Tolis Tape Tools, и даже больше, можно добиться вызовами бесплатной IBMовской утилиты ITDT с различными параметрами командной строки. Например, работать с архивами tar на ленте можно командами вроде такой:

и тому подобными. К сожалению, автору неизвестно, работает ли ITDT с накопителями других фирм.

Однако, в качестве рабочего предлагается выбрать несколько иной механизм. Корпорацией IBM разработана ленточная файловая система LTFS с открытым исходным кодом, распространяемая в том числе и для macOS.

Тут существует нюанс, заключающийся в том, что разные производители ленточных устройств выпускают свои собственные версии LTFS, поддерживающие свои устройства. Так как автор использует ленточный накопитель IBM, то и LTFS установил от IBM. Для накопителей других фирм, возможно, потребуются их собственные порты LTFS. И существует универсальная реализация openLTFS на гитхабе и хоумбрю.

Для нас важно, что LTFS использует функцию партиционирования носителя, и поэтому может работать с устройствами и картриджами, начиная с поколения LTO-5.

Итак, в нашем случае скачиваем с сайта IBM продукт IBM Spectrum Archive Single Drive Edition для macOS, который как раз и включает реализацию LTFS. Без всяких приключений устанавливаем продукт его собственным инсталлятором. По ходу дела он устанавливает также пакет FUSE, при этом в системных настройках придётся подтвердить авторизацию умного программиста по имени Anatol Pomozov, от которой в данном случае зависит целая IBM. Респект и уважуха этому человеку.

Целесообразно сразу в файле /Library/Frameworks/LTFS.framework/Versions/Current/etc/ltfs.conf.local прописать строчку:

задающую монтирование ленты по умолчанию со сбросом буфера записи через 1 минуту неактивности (по умолчанию 5 минут).

Наконец, всё готово для подключения. Подключаем цепочку: Mac – адаптер T3/T2 – кабель Thunderbolt – конвертер ATTO – кабель SAS – ленточный накопитель (выбор из нескольких портов на Маке, конвертере и накопителе неважен). Включаем питание конвертера. Включаем питание ленточного накопителя. Дожидаемся окончания инициализации накопителя по его индикации.

Ура! Получаем (в обычной для IBM диагностической манере):

307 LTFS14000I LTFS starting, LTFS version 2.4.2.0 (10418), log level 2.
307 LTFS14058I LTFS Format Specification version 2.4.0.
307 LTFS14104I Launched by «ltfs -o device_list».
307 LTFS14105I This binary is built for Mac OS X.
307 LTFS14106I GCC version is 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66)).
307 LTFS17087I Kernel version: Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6

15/RELEASE_X86_64.
307 LTFS17085I Plugin: Loading «iokit» tape backend.
Tape Device list:.
Device Name = 0, Vendor Product Serial Number = **********, Product Name =[ULT3580-TD5].

Вставляем кассету, дожидаемся загрузки и форматируем:

Здесь параметр -d задаёт номер накопителя (всегда ноль, если он единственный, но опускать в этой команде нельзя), -n – имя ленты (можно его не указывать), а параметр -r требует размещать содержимое файлов .DS_Store, не превышающих по размеру 10 мегабайт, в индексном (т.е. предназначенном для каталогов) разделе ленты вместо раздела данных.

Пошла таинственная жизнь в ленточном накопителе. Ждём пару минут, получаем в ответ:

LTFS15000I Starting mkltfs, LTFS version 2.4.2.0 (10418), log level 2.
LTFS15041I Launched by «mkltfs -d 0 -nTest -r size=10M/name=.DS_Store».
LTFS15042I This binary is built for Mac OS X.
LTFS15043I GCC version is 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66)).
LTFS17087I Kernel version: Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6

15/RELEASE_X86_64.
LTFS15003I Formatting device ‘0’.
LTFS15004I LTFS volume blocksize: 524288.
LTFS15005I Index partition placement policy: size=10M/name=.DS_Store.
LTFS11337I Update index-dirty flag (1) — NO_BARCODE (0x0x1021081e0).
LTFS17085I Plugin: Loading «iokit» tape backend.
LTFS30810I Opening a device through iokit driver (0).
LTFS30814I Vendor ID is IBM.
LTFS30815I Product ID is ‘ULT3580-TD5 ‘.
LTFS30816I Firmware revision is H976.
LTFS30817I Drive serial is **********.
LTFS17160I Maximum device block size is 1048576.
LTFS11330I Loading cartridge.
LTFS30854I Logical block protection is disabled.
LTFS11332I Load successful.
LTFS17157I Changing the drive setting to write-anywhere mode.
LTFS15049I Checking the medium (mount).
LTFS30854I Logical block protection is disabled.
LTFS15010I Creating data partition b on SCSI partition 1.
LTFS15011I Creating index partition a on SCSI partition 0.
LTFS17165I Resetting the medium’s capacity proportion.
LTFS11097I Partitioning the medium.
LTFS11100I Writing label to partition b.
LTFS11278I Writing index to partition b.
LTFS30808I READ_ATTR (0x8c) returns -20501.
LTFS30865I READ_ATTR returns Invalid Field in CDB (-20501) 0.
LTFS30836I Cannot read attribute (-20501).
LTFS11336I The attribute does not exist. Ignore the expected error.
LTFS17235I Writing index of NO_BARCODE to b (Reason: Format, 0 files) **********.
LTFS17236I Wrote index of NO_BARCODE (b, **********).
LTFS11337I Update index-dirty flag (0) — NO_BARCODE (0x0x1021081e0).
LTFS11100I Writing label to partition a.
LTFS11278I Writing index to partition a.
LTFS30808I READ_ATTR (0x8c) returns -20501.
LTFS30865I READ_ATTR returns Invalid Field in CDB (-20501) 0.
LTFS30836I Cannot read attribute (-20501).
LTFS11336I The attribute does not exist. Ignore the expected error.
LTFS17235I Writing index of NO_BARCODE to a (Reason: Format, 0 files) 9068025555.
LTFS17236I Wrote index of NO_BARCODE (a, **********).
LTFS15013I Volume UUID is: 3802a70d-bd9f-47a6-a999-eb74ffa67fc1.
LTFS15019I Volume capacity is 1425 GB.
LTFS30854I Logical block protection is disabled.
LTFS15024I Medium formatted successfully.

Монтируем отформатированную ленту:

Получаем ещё пару минут работы накопителя, диагностику:

307 LTFS14000I LTFS starting, LTFS version 2.4.2.0 (10418), log level 2.
307 LTFS14058I LTFS Format Specification version 2.4.0.
307 LTFS14104I Launched by «ltfs /Volumes/LTFS/».
307 LTFS14105I This binary is built for Mac OS X.
307 LTFS14106I GCC version is 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66)).
307 LTFS17087I Kernel version: Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6

15/RELEASE_X86_64.
307 LTFS14063I Sync type is «time», Sync time is 60 sec.
307 LTFS17085I Plugin: Loading «iokit» tape backend.
307 LTFS17085I Plugin: Loading «unified» iosched backend.
307 LTFS14095I Set the tape device write-anywhere mode to avoid cartridge ejection.
307 LTFS30810I Opening a device through iokit driver (0).
307 LTFS30814I Vendor ID is IBM.
307 LTFS30815I Product ID is ‘ULT3580-TD5 ‘.
307 LTFS30816I Firmware revision is H976.
307 LTFS30817I Drive serial is **********.
307 LTFS17160I Maximum device block size is 1048576.
307 LTFS11330I Loading cartridge.
307 LTFS30854I Logical block protection is disabled.
307 LTFS11332I Load successful.
307 LTFS17157I Changing the drive setting to write-anywhere mode.
307 LTFS11005I Mounting the volume.
307 LTFS30854I Logical block protection is disabled.
307 LTFS17227I Tape attribute: Vendor = IBM.
307 LTFS17227I Tape attribute: Application Name = LTFS.
307 LTFS17227I Tape attribute: Application Version = 2.4.2.0.
307 LTFS17227I Tape attribute: Medium Label =.
307 LTFS17228I Tape attribute: Text Localization > 307 LTFS17227I Tape attribute: Barcode =.
307 LTFS17227I Tape attribute: Application Format Version = 2.4.0.
307 LTFS17228I Tape attribute: Volume Lock Status = 0x00.
307 LTFS17227I Tape attribute: Media Pool name =.
307 LTFS14111I Initial setup completed successfully.
307 LTFS14112I Invoke ‘mount’ command to check the result of final setup.
307 LTFS14113I Specified mount point is listed if succeeded.

И вот она, наша лента на рабочем столе, с именем Test(ltfs)! Безымянная же лента получит имя OSXFUSE Volume 0 (ltfs).

Теперь можно с ней работать.

Вообще-то надо иметь в виду, что желательно не злоупотреблять просмотром содержимого каталогов ленты в окнах файндера, так как это невероятно затратная для LTFS операция, а лучше работать всё-таки командами терминала, либо просто сбрасывать резервно копируемый каталог оптом на ленту, как показано в окне выше.

Существует, кстати, специально написанная IBM утилита ltfs_copy и её клоны, предназначенная для более эффективного копирования между лентой и диском, но пока автору не удалось их найти в открытом доступе при поверхностном поиске.

Размонтировать ленту можно командой:

или просто выкинуть в корзину.

Вообще-то в природе существуют какие-то графические оболочки для macOS для облегчения этих действий, но нам ли, после таких извращений, бояться набрать несколько строчек в терминале?

Как побочное следствие, получаем возможность через кабель SAS/4*eSATA подключать внешние диски eSATA.

Источник