MAC OSXで複数の外部ハードディスクのボリューム名が同じだったときの動きについて

MAC OSX(本記事はバージョン”10.11.6″のときに確認したものです)で、USBなどで接続する外部ハードディスク(以下、外部HDD)のボリューム名(外部HDDをFinderで見たときの名前)が同じだったときにどういう動きになるのか?が気になったので、調べてみました。

ボリューム名の変更方法

調査にあたって、元々使っていたBUFFALOの外部HDDのボリューム名が「EXHDD01」だったので、追加で接続する外部HDD(裸のHDDをUSBで接続させました)のボリューム名も同じ「EXHDD01」に変更しました。以下にボリューム名の変更方法を書いておきます。

Finderで外部HDDのボリューム名変更

Finderの左サイドバーに表示される外部HDDを右クリックして、「”<ドライブ名>”の名称変更」をクリックして変更できます。

同一ボリューム名の外部HDDを接続

BUFFALOの外部HDD、もう1台の外部HDDの順で接続しました。その時の状態をディスクユーティリティでみると以下のようになっています。

BUFFALOの外部HDD

Disk 01

もう1台の外部HDD

Disk 02

見比べてみると、ボリューム名は同じであることがわかります。実際、Finderでも同じボリューム名で表示されます。では、何が違うのか?
ディスクユーティリティのマウントポイントを見てみてください。1台目のBUFFALOの外部HDDは「/Volumes/EXHDD01」となっていますが、2台目の外部HDDは「/Volumes/EXHDD01 1」となっています。これはOS側で同じボリューム名の場合に、後ろに自動的に数字を付与して別名でマウントしてくれているためです。

まとめ

ボリューム名は同じにしても問題はなさそうです。Finderで同じ名前で表示されるため、通常はボリューム名は別々にしたほうがいいかと思いますが、用途によっては同じボリューム名にいても大丈夫そうです。

MAC OSXで複数の外部ハードディスクのボリューム名が同じだったときの動きについて

Mac OSXでSquidを導入して認証付Proxyを突破させる

会社にてテスト用に入手したMacBook Pro。普段使わずに放っておくにはもったいないので、Macで仕事ができるか?ということで色々と使ってみています。そんな中で、Windowsでも同様につまづく、Proxyの問題にMacのOSXでもぶち当たりました。

会社ではインターネットに接続する際に、社内のProxyを経由して接続しないといけないのですが、こいつが認証も必要なためにアプリによってはうまく処理できなくて動かないことが多々あります。例えば、Office 2016のインストールやSublimeTextのPackageのインストールなんかは、引っかかってうまく動作してくれません。
なお、Windowsだとローカルで動かすお手軽なProxyがあるので、そいつを動かして回避しています。ちなみに今使っているのはyappaってやつで、設定で会社のProxyのアドレス、ユーザIDおよびパスワードを指定するだけなので簡単です。

で、Macで同じようにローカルにProxyをたてて回避しようと思って、簡単に使えるProxyがないものか?と調べてみましたが、ありませんでした。過去にdolipoってアプリがあったのですが、既に公開されていたサイトもクローズされていて利用できませんでした。

でで、下記のページに行き着き、Squidを導入して回避することに決めました。
Proxyならnginxじゃね?って思うところはあるのですが、設定が面倒なイメージがあったのと、参考になるページのあるSquidにした次第です。

以下、手順です。って、上記ページの内容のままですけどね。
いちよう私のSquidの設定も吊るしておきます。

1. Homebrewの導入

Squidをbrewを使ってインストールするので、まずはHomebrewを導入します。
ちなみにココでもProxyを経由する必要があるので、Proxyの設定をしてからインストールを実行します。

認証付きProxy環境下でHomebrewのインストール
Proxyのポートはココでは「8080」としていますが、適宜変更してください。

$ export http_proxy=http://<認証ユーザ>:<認証パスワード>@<会社のProxyのアドレス>:8080
$ export https_proxy=$http_proxy
$ export ALL_PROXY=$http_proxy

してから

$ ruby -e “$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)”

する。

2. Squidの導入

2.1 Squidのインストール

brewでSquidをインストールします。下記のコマンドだけでOKです。こんなに簡単にできちゃうのね。

$ brew install sqid

2.2 squid.confの編集

Squidのインストールが完了したら、会社のProxyを経由して接続するための設定を行うために、「/usr/local/etc/squid.conf」を編集します。
squid.confの「INSERT YOUR …」の下に下記の記述を追記しただけです。ココでもProxyのポートは「8080」としていますが、適宜変更してください。
squid.confの全体は「A. squid.conf」に吊るしているので、そちらを見てください。

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

visible_hostname unknown
hosts_file /etc/hosts
cache_peer <会社のProxyのアドレス> parent 8080 7 no-query login=<認証ユーザID>:<認証パスワード>
cache_peer_access <会社のProxyのアドレス> deny localnet
never_direct allow !localnet

3. Squidの起動

Squidの起動するには、下記のコマンドを実行すればOKです。

$ /usr/local/sbin/squid

3.1 Squidの自動起動設定

OS起動時に自動的に起動させたいので、ユーザのログイン項目に上記のコマンドを追加します。
なお、ファイルを選択する際に「/usr」フォルダが表示されないのですが、「ctrl + shift + G」で移動することができます。

4. ネットワークの設定

最後にローカルのProxyであるSquidを経由してインターネットに接続するための設定として、ネットワークのプロキシの設定を「localhost:3128」に設定します。ポートはsquid.confのデフォルト設定のままなので「3128」となっています。

A. squid.conf

#
# Recommended minimum configuration:
#

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80      # http
acl Safe_ports port 21      # ftp
acl Safe_ports port 443     # https
acl Safe_ports port 70      # gopher
acl Safe_ports port 210     # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280     # http-mgmt
acl Safe_ports port 488     # gss-http
acl Safe_ports port 591     # filemaker
acl Safe_ports port 777     # multiling http
acl CONNECT method CONNECT

#
# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on &quot;localhost&quot; is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

visible_hostname unknown
hosts_file /etc/hosts
cache_peer <会社のProxyのアドレス> parent 8080 7 no-query login=<認証ユーザID>:<認証パスワード>
cache_peer_access <会社のProxyのアドレス> deny localnet
never_direct allow !localnet

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /usr/local/var/cache/squid 100 16 256

# Leave coredumps in the first cache dir
coredump_dir /usr/local/var/cache/squid

#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp:       1440    20% 10080
refresh_pattern ^gopher:    1440    0%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern .       0   20% 4320
Mac OSXでSquidを導入して認証付Proxyを突破させる

【解決済】mac(OSX 10.11.5)のファイル共有にiPhone, iPadから接続できなくなった

ComicShareというiOSアプリでmacのファイル共有に接続できなくなった。何が起こったのかわからず、試行錯誤。Wifiのルーターが何かやっているのか?と思って調べたけど、何も関係ありそうなものはない。FirewallもOFFにしてもつながらない。

困った。。。

冷静になってコンソール(ユーティリティ → コンソール.app)のログを見ると、下記のログが出力されていた。

2016/06/02 1:02:43.756 smbd[4060]: session_setup_transact: activate_signing returned status 0xc000a000: status

このログでようやくそれっぽい情報にたどり着いた。

読んでみると以下の回答あり。

I can confirm that the issue is indeed that SMB signing is now forced on the Mac server by default. The good news: this can be disabled manually by editing /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist and add a new key:
<key>SigningRequired</key>
<false/>
After restarting the smbd process, the apps on my iPad can connect again, as before the 10.11.5 / server 5.1.5 upgrade.

どうやらOSXの10.11.5からはSMB接続する際にセキュリティ署名がデフォルトで強制になったようです。なんか、似たような話が前にもあったような。。。

このデフォルトの設定をオフにするために、書かれている通りに「/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist」を開いて、下記の2行を<dict>タグ内の1番下に書き加えた。

<dict>
~
<key>SigningRequired</key>
<false/>
</dict>

んでもって再起動した後に、繋いでみたら・・・つながったよ!!!
他のiOSアプリでもファイル共有に対してSMB接続できなくなった場合には、試してみてください。とはいえ、セキュリティレベルは下がるので、自己責任にてお願いします

【解決済】mac(OSX 10.11.5)のファイル共有にiPhone, iPadから接続できなくなった

MacBook Pro (15-inch, Mid 2010)上のWindows7(Boot Camp)をWindows10にアップグレード無事成功

カミさんが使っているMacBook Pro (15-inch, Mid 2010)は、Boot CampでWindows 7 64bitを動かしていました。特に不便はなかったと思うのだけど、最近のニュースでWindows 10への無償アップグレードは後3ヶ月というニュースにまんまとノセられてw うっかりWindows 10へアップグレードしてしまいました。

ずっと表示されていたWindows 10へアップグレードしませんか?では、ハードウェアの互換性についてはBlueToothのみがサポートされていないと表示されていたので、まぁ問題ないだろうと思ってたとおり、ほぼ問題なくアップグレードできました。この時点で確かにBlueToothはデバイスマネージャ上で、ドライバを更新しろという警告表示が出ている状態です。

BlueTooth以外で発生した問題は、ボリューム調整などを実行できるファンクションキーが動作しなくなったってこと。これは地味に困るのでググッて調べてみたところ、Boot Camp Support Softwareを再インストールすればいいことがわかる。早速、MacBook Pro (15-inch, Mid 2010)用のをダウンロード。

[手順]
Windows 7→Windows 10へアップグレード後に、実施した手順です。

  1. インストールされていた「Apple Application Support (32bit)」と「Apple Application Support (64bit)」をアンインストール
  2. ダウンロードしたBoot Camp Support Softwareを解凍して、BootCampフォルダの「setup.exe」を実行
  3. 途中、RealTekのドライバのインストーラがいつまでたっても終わらない箇所に遭遇。こちらはタスクマネージャで「RealtekSetup.exe」を強制終了(RealTekのフォルダを事前に消しておいてもいいみたいです)
  4. 後は放っておけばインストールは終わり、再起動

それ以外の手順では、GPUの「NVIDIA GeForce GT 330M」のドライバをWindows 10 64bit版の最新のものに更新しておきました。

うちのMacBook Proは以上で再起動後にはファンクションキーも無事に動作し、BlueToothのドライバの警告の表示も消えました(実際にBlueToothの動作については確認していません)。

[参考]

MacBook Pro (15-inch, Mid 2010)上のWindows7(Boot Camp)をWindows10にアップグレード無事成功

BetterTouchToolの設定の見直し

MacBook Proを新調し、感圧タッチトラックパッドになったのですが、3本指クリックが重く感じるようになりました。3本指クリックにはBetterTouchToolで「Command + W」を割り当てて結構使うので、これは!と思いBetterTouchToolの設定を見直すことに。

今まではGlobalの設定で、下記の設定をしていました。

  • 3 Finger Swipe Down / End (End of the Page)
  • 3 Finger Swipe Up / Home (Beginning of the Page)
  • 3 Finger Click / Command + w
  • 3 Finger Tap / Middle Click

これをとりあえず、GlobalではEndとHomeのみを残してChromeのみで下記の設定をするように変更してみた。

  • 3 Finger Swipe Left / Shift + Control + Tab
  • 3 Finger Swipe Right / Control + Tab
  • 2 Finger Tap / Middle Click
  • 3 Finger Tap / Command + w

これで、2本指タップでお気に入りなどから新規タブで開いて、3本指スワイプでそのタブに移動って感じになるので、まずはこの設定で使ってみようかと。
閉じるのは3本指タップになったことで、快適に閉じれるようにはなりました♪

そうそう、トラックパッドのクリックの設定も「中」から「弱い」に変更もしてみてます。かなり軽くなってこれまた具合がいいっす。

設定に際し、下記のサイトを参考にさせて頂きやした。

20151028 BetterTouchTool 01

20151028 BetterTouchTool 02

BetterTouchToolの設定の見直し

1Passwordで脆弱性?

Gigazineの1Passwordの平文のメタデータから個人情報を盗みとられるおそれがあるという記事で騒ぎになっているようです。

これについて下記のサイトに何が問題でどうすればいいかについて、非常にわかりやすく書いています。1Passwordを利用している方は、目を通しておいて損はないと思います。

ワシも1Passwordは利用しているのですが、iCloudと同期しているぶんには問題ないようです。ビックリさせやがって!

1Passwordで脆弱性?

MacBook Pro 15inch (Mid 2010) のGPU Panic問題について

OS X Mavericksにアップグレードしたあたりからでしょうか。いきなりOSが落ちるというのは頻繁に発生するようになりました。よく起こっていたのは、Google Chromeで普通にブラウジングしているときです。

再起動後に落ちていた原因が「GPU Panic」だと知る。

この問題について調べたところ、NVIDIAのGeForceのチップに問題があるということだった。色々と調べると無償対応もしているという話だったのだけど、購入から3年までで、Marvericksがリリースされたのは2013年の10月で、既に3年経過済み。。。今まで起きてなかったから気が付かなかっただけなのに、、、って感じで一旦諦めていました。

そこからはgfxCardStatusを利用し、騙し騙し使っていました。このツールも万能ではなく、例えばGoogle Chromeだと設定でどんなにGPUを使わないようにしても、プログラムを終了するタイミングでGPU切り替えてくれて、戻すのを忘れて使ってて落ちるということはよくありました。
Pixelmatorに至っては、GPUに切り替えないと画像が表示されないという致命的な状態で。かといってGPUに切り替えると、もうね瞬殺でしたね。1つの画像を加工するのに、何度落ちたことか。。。

てな感じで、ソフトウェアで回避することはできないと確信していました。
で、いい加減あきらめて修理にだすかと思い、2015/07/27にようやくGenius Barに持ち込みました。さすがに10万とか修理費にかかったら諦めようと思っていましたが、税込みで4万円ほどだったので、即断で修理を依頼。で、本日(2015/07/31)にロジックボードの交換されたMBPを受け取ってきて今に至ります。

持ち込んだ際に言われたのが、パーツ関連は製品がリリースされてから5~6年ぐらいしか確保していないため、今度何か故障したらもう交換用のパーツは無いかもしれないとは言われました。それを聞いて、タイミングとしては修理に出してラッキー!とは思いましたねw

本問題で使い続けている人は、もうあまりいないかもしれませんが、コレばっかりはハードの問題なので、早めに修理に出すことをオススメします。今まで普通に使ってても発熱してファンがブンブン回っていたのも、起きなくなってるし♪

MacBook Pro 15inch (Mid 2010) のGPU Panic問題について