いまさらm1 macbook air

f:id:hate_nattou:20210213225906j:plain:w240

概略

いまさらですが、m1 macbook airに乗り換えました。

大きな違いは、すでにYouTuberの方々が語っていると思うので省略。

私が使ってみてわかった細かい差分や発生した問題について記します。

環境

ハードウェア関係

ディスプレイ出力

マウスカーソルの動きがちらちらしないように、60Hzは必須。

これまでは、データ転送速度をUSB2.0で我慢しなくてはならなかった点がm1 macで解決。

写真を交えて詳しい解説をしてくれているウェブサイトはこちら。

https://sekinesan.jp/blog/2021/02/01/25855sekinesan.jp

開発系

Pythonライブラリ: lxmlのインストール失敗

lxmlはPythonのライブラリの1つ。

lxmlのバージョンを上げることで解決。

  • 4.2.6では動作NG
  • 4.6.4にてインストール成功
  • 下記のウェブサイトによれば4.6.2の時点でOKだったらしい

degitalization.hatenablog.jp

Docker: 旧マシンにて使っていたPython開発環境のイメージが動かない

旧マシンから移行する際に、VSCodeの設定ファイルである .devcontainer.json へ以下を付け加える。

platform: linux/amd64

ChromeDriverがクラッシュ -> 未解決

Dockerが利用できるメモリー量を増やす(2GB->4GB) webdriver_manager==3.4.2 -> 3.5.2へ変更

運用系

TimeMachine with Samba -> 未解決(ワークアラウンドあり)

Raspberry Pi4 で構築したSambaサーバーにTimeMachine用のディレクトリを作成してMacのバックアップを作っていた。

旧マシンでは動作していたが、新マシンでは動作しない。

アクセス権に関するエラーが発生している(スクリーンショットがこれ)

f:id:hate_nattou:20220109204314p:plain:w240

TimeMachineのログでは以下のように出力されていた。

# Timemachineのログ(TimemachineEditorで表示)
2022/01/09 15:00:22 Time Machine NAConnectToServerSync failed with error: 13 (Permission denied) for url: smb://[ユーザー名]@RASPBERRYPI._smb._tcp.local./TimeMachine
2022/01/09 15:00:22 Time Machine Backup failed (19: BACKUP_FAILED_TARGETVOL_NOT_MOUNTED - The backup disk could not be resolved, or there was a problem mounting it.)

Permission deniedされて、マウントに失敗しています

他のディレクトリにはアクセスできているので、ユーザーやパスワードの関係ではない。

パーミッションも問題ないことは確認済み。

時間が異なるけれど、sambaのログには下記のようなログが継続して出力されていました。

# /var/log/samba/log.macbook-air
[2022/01/09 18:24:20.239211,  0] ../source3/modules/vfs_fruit.c:6995(fruit_tmsize_do_dirent)
  fruit_tmsize_do_dirent: tmsize overflow: bandsize [16777216] nbands [1847]
[2022/01/09 18:24:20.239424,  0] ../source3/smbd/dfree.c:125(sys_disk_free)
  sys_disk_free: VFS disk_free failed. Error was : 無効または不完全なマルチバイトまたはワイド文字です

ディスクの容量不足のように見えるけれど、空き領域はたくさんあるのですよね・・・。

Rasbperry Pi側の/etc/samba/smb.conf(主な部分を抜粋)は下記。

[global]
;[@2022/01/09]
   min protocol = SMB2
   vfs objects = fruit streams_xattr
   fruit:metadata = stream
   fruit:model = MacSamba
   fruit:posix_rename = yes
   fruit:veto_appledouble = no
   fruit:wipe_intentionally_left_blank_rfork = yes
   fruit:delete_empty_adfiles = yes
   fruit:zero_file_id = yes

[TimeMachine]
   comment = Backup for MacBook
   browseable = yes
   path = /mnt/hdd1/TimeMachine
   guest ok = no
   read only = no
   valid users = [ユーザ名]
   hosts allow = 192.168.1. fe80::/10
   vfs objects = catia fruit streams_xattr
   fruit:time machine = yes
   fruit:time machine max size = 200G

globalの部分にある ";[@2022/01/09]" の部分は、

wiki.samba.org

を見て、今回追加した部分。

vfs objects の値を "acl_xattr catia fruit streams_xattr" とすればよいという解決策もネット上にはあった( Big Sur + SMB based Time Machine | Apple Developer Forums)が、私の環境では有効な解決策にならなかった。

ワークアラウンド

ワークアラウンドは、/etc/samba/smb.confで最後の行をコメントアウト

;   fruit:time machine max size = 200G

そのあと、sambaを再起動

sudo systemctl restart smbd

この設定は、TimeMachineで使う領域を200GBに制限し、値を超えたら古いバックアップから削除するためのもの。

当然ながら、容量の数字は他の値でもよい。

この設定をコメントアウトして無効化すると、macからTimeMachineのディレクトリを正常にマウントできるようになった。

この現象は、debian buster && armv7(Raspberry Pi)という条件で発生していたという報告があり、私も同じ構成。他の構成でも発生するのかどうかは未知数。

bugzilla.samba.org

Samba 4.11系や4.12系では修正されているようだが、raspbian OS用にはビルドされていないようで、apt-get upgradeではインストールできない。

今回は、ワークアラウンドでしのぐことにします。

もうひとつの注意ポイント

もうひとつには、
システム環境設定 -> セキュリティとプライバシー -> プライバシー -> フルディスクアクセス
にて、smbdにチェックを入れることも必要。

デフォルトはチェックが入っておらず、動きません。

macOSの機能であるTimeMachineを、OSの他機能で止めちゃうとはこれ如何に・・・。

TimeMachineはバックグラウンドで動作しているから、警告のポップアップもでないのです。

まとめ

M1に限った問題にあたっても、解決策は意外と簡単に見つかりました。

どちらかというとOS(Big Sur)の問題であることも多いよう。

CPUのアーキテクチャ変更というのは、かなりリスクが伴うものであるが、意外とスムーズに進んでいるようす。

けれど、それもこれも、m1 macの発売から1年が経過していくなかで、先人のみなさまが解決策をネットに公開してくれているおかげ。本当に感謝!