【過去記事まとめ】UbuntuからUSBに書き込めない問題の解決方法など個人ブログで掲載した過去記事まとめ

# はじめに

この記事は過去に個人ブログで掲載していた記事の一部を１つにまとめたものです。

:::note warn
警告
2022年7月から2023年7月までの期間に執筆した内容のため、情報が古い可能性があります。
:::

## 環境

OS: Ubuntu 22.04 LTS

# 【Ubuntu】USBに書き込みができない問題の解決方法

## 発生した問題

学校で少し特殊な課題があり、紙媒体での課題提出を求められました。そこで、PDF形式で課題を出力し、学校のプリンタで印刷しようと考えました。
さっそく完成した課題をファイルマネージャでUbuntuからUSBに移そうとしたのですが、ドラッグ・アンド・ドロップができませんでした。

ファイルマネージャではエラーメッセージが表示されなかったため、ターミナルを起動し、「mv」コマンドを使用してファイルを移動させることにしました。具体的には以下のようなコマンドを実行しました。なお、ファイル名やパスは実際のものと異なる場合があります。

```bash
$ mv ~/Documents/kadai.pdf /media/xxx/usb/
mv: デバイス間移動失敗: '/home/xxx/Documents/kadai.pdf' から '/media/xxx/usb/kadai.pdf' 。移動先を削除できません: 読み込み専用ファイルシステムです
```

エラーメッセージから、USBが読み込み専用（read only）としてマウントされてしまっていることが確認できました。これは私の憶測ですが、WindowsでフォーマットしたUSBを使用したため、Ubuntuが上手く認識できなかったのではないかと考えました。

## エラーの解決方法

ターミナルで「mv」コマンドを実行してみた結果、読み込み専用としてマウントされてしまっていることが原因だと判明しました。念のため、「mount」コマンドでUSBをどのようにマウントしているのか確認してみましょう。

```bash
$ mount | grep usb
/dev/sda1 on /media/xxx/usb type vfat (ro, ...
```

roという記述から、確かに読み込み専用としてマウントされていることが確認できます。

「mount remount」コマンドで再マウントを行い読み書き可能な状態に変更します。

```bash
$ sudo mount -o remount,rw /media/xxx/usb
$ mount | grep usb
/dev/sda1 on /media/xxx/usb type vfat (rw, ...
```

「mount」コマンドの実行結果がroからrwに変化していることが確認できると思います。USBを書き込み可能な状態でのマウントに成功しました。
この状態で「mv」コマンドを実行し、ファイルの移動を試してみます。

```bash
$ mv ~/Documents/kadai.pdf /media/xxx/usb/
$ ls /media/xxx/usb/
kadai.pdf
```

無事、ファイルをUSBに移動させることができました。

## まとめ

今回の記事では、UbuntuでUSBに書き込みができない問題の解決方法を紹介しました。

私はWindowsとUbuntuをデュアルブートして使っているのですが、OS間でファイルを共有する用途の共有フォルダにファイルを移すことができなかったことが過去ありました。その時も共有フォルダを読み込み専用としてマウントしていることが原因でした。

マウントの不具合が原因で書き込みができなくなることは意外と多く発生するのかもしれません。

# Ubuntuで画面共有ができない問題の解決方法

## 発生した問題

Discordで通話しながらコーディング作業をしているときに画面共有をしたところ、配信画面が真っ黒になってしまい正常に共有することができませんでした。Google Chromeなどのアプリを直接共有する場合は正常に表示されます。

![discord-share-failed.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594132/5ccd4f05-0230-55df-e82b-459ac465c6e9.png)

Discordで画面共有をすると真っ暗になっている。

![zoom-share-failed.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594132/0103ab7e-4e05-1f26-1155-ec5bc24d8fa0.png)

Zoomでは画面共有の対象すら表示されていない。


Zoomなどのアプリでも同様に画面共有が行えなかったので、アプリケーション側ではなくUbuntu側の問題であると考えられます。

## 解決方法

custom.confを書き換え、PCを再起動することで解決することができます。

まずは以下のコマンドを実行してcustom.confを開きます。


```bash
$ sudo vim /etc/gdm3/custom.conf
```

そして以下の行を見つけ出してください。私の環境では7行目にありました。

```
#WaylandEnable=false
```

続いてコメント文の先頭にある「#」を削除してください。

```
WaylandEnable=false
```

最後にPCの再起動を行えば無事、画面共有ができるようになっていると思います。

![discord-share-succeed.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594132/530ab4d3-ae03-67f5-07fc-7efd33aa2340.png)

## 参考

問題の解決方法は[こちら](https://askubuntu.com/questions/1270710/black-screen-during-screen-share-in-ubuntu-18-04)のサイトを参考にしました。

# Android Studioのプロキシ設定を削除したのにGradle buildでプロキシを通してしまう問題

この問題はUbuntuにFlutterをインストールし、初期のプロジェクトで動作確認を行おうとしたときに発生しました。

Android Studioは学校で利用するため普段はプロキシを設定しています。しかし今回の場合は自宅で動作確認を行うので、設定画面からプロキシを無効にしました。

新規Flutterプロジェクトを作成し何もいじることなくmain.dartを実行したところ、ホストのIPアドレスが判定できなかった、という例外が発生しアプリが起動しませんでした。
以下がそのときの例外メッセージです。

```
Exception in thread "main" java.net.UnknownHostException <プロキシ>
```

原因はユーザーのホームディレクトリにある`.gradle/gradle.properties`というファイルにプロキシの設定が残っている為でした。このファイルを削除することで例外が発生しなくなります。
アプリ内にも同様のファイルが存在しますが、ホームディレクトリの隠しフォルダ.gradleにあるgradle.propertiesファイルの方であるということに注意してください。

https://stackoverflow.com/questions/49555418/android-studio-on-mac-remove-proxy-settings

gradleの設定ファイルを削除することで例外が発生しなくなりましたが、今度は起動時のgradle task assembledebugが一向に終わらないという問題が発生しました。

こちらの問題は以下の記事を参考にプロジェクトのSDKを設定し、gradleのクリーンとビルドを行うことで解決しました。

https://saka24.blue/index.php/2021/05/12/android-studio_assembledebug/

https://flutter-square.com/build-never-ends/

ビルドが終わり、再度main.dartを実行すると無事にFlutterアプリが起動するようになりました。

![gradle_proxy_flutter.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594132/9cd2a562-447d-bf58-38c3-7dd0ffee9714.jpeg)