最高裁判所発表の相続放棄の申述受理件数が令和５年度で，２８２，７５８件で，令和４年度と比較して，２２，２８８件増になったようです。
（最高裁判所事務総局「令和５年 司法統計年報 3家事編」６頁）
相続放棄の理由としては，昔から負債総額が大きいときに選択されることが多いのですが，そのほかに，いわゆる「負の不動産」といわれる，処分や維持の難しい不動産から逃れようとしている場合も多いです。
（参考：ＦＮＮ「【実家の相続を放棄したい理由ランキング】経験者201人アンケート調査」）
相続放棄の申述は，申立の可能期間が３か月以内となっているため，早めに結論を出して，早めに司法書士や弁護士にご依頼ください。
世間では，Windowsパソコンで世界規模の障害が発生し，航空会社のシステム等で影響があったようです。
（参考：TBS NEWS DIG「Windows世界規模システム障害 原因はセキュリティソフト」）
セキュリティソフトの不具合のみで，世界規模の障害が起きてしまうとはとても恐ろしいことですし，この世界規模の障害のようにWindowsパソコンでブルー画面が発生した場合には，その原因がわかるまで非常にあせってしまいます。
当事務所でもいろいろなシステムを利用していますが，その一つにデータ保管のクラウドサーバーとしてNextcloudサーバーを利用しています。
クラウドサーバーは，一般的にgoogleドライブやOne Driveを利用する方法もありますが，特に重要な個人情報を扱うため，さすがにグローバルサーバーを安易に利用することができません。どこで急にハッキングされたり，漏れたりするかわからないからです。また，一般的なクラウドサービスは，そのサービス会社の従業員であれば，中身を覗けるという情報も存在します。
その点，自社のNextcloudでは，物理的に自社内でFedoraサーバーを構築しており，あくまでもイントラネット上でのみ使用しているため，外部に情報が出ることはまずあり得ません。よって，セキュリティ的には安心なのですが，問題なのは不具合が発生した場合には自身で修復しなければなりません。
最近の問題点として，Nextcloudが29.0.3にアップデートしたところ，アクセス中「Internal Server Error」が発生しました。error_logを調べると
[時刻] [core:alert] [pid xxxx:tid xxxx] [client 127.xxx.xxx.xxx:xxxx] /usr/share/nextcloud/.htaccess: ErrorDocument not allowed here
が記録されました。
全くデータの同期がされなくなり，大変困りましたが，Fedoraでは以下の方法で修復できました。
vi /etc/httpd/conf.d/nextcloud-(利用しているもの).inc
#Apache 2.4 以降に追記↓
AllowOverride All
FedoraでNextcloudを利用するかたは，参考にしてみてください。
市区町村役場が発行する住宅用家屋証明書（所有権保存登記や抵当権設定登記の登録免許税を低減するために必要な証明書）を取得する際には，通常，あらかじめ，個人の居住の用に供したことを証明するため，その家屋に住所を移転しておく必要があります。
（租税特別措置法第７２条の２，同施行令第４１条等）
住宅用家屋証明書があれば，登記の手数料となる登録免許税が保存登記で０．４％が０．１５％となり，かなりの登記費用の低減となります。住宅用家屋証明書の確実な取得が必須となるため，建物の完成後，住所を移してから登記する順番となるため，登記の申請をする際，かなり忙しい状況で住宅用家屋証明書を取得しなければなりません。
本年７月から住宅用家屋証明書の取得の際，市区町村への住民票の写しの提出がなくとも，「入居見込み確認書」の提出で対応できるようになったようです。
（国土交通省「住宅用家屋の所有権の保存登記等に係る特例措置」の証明書の様式等 参照）
上記の確認書は宅建業者の証明となりますので，今後，家屋の買主様と連携を密にしてその確認をしていただくことになっていきそうです。
令和６年分の財産評価基準（路線価）が公表されました。
場所「国税庁：令和６年分財産評価基準を見る」
土地の価格には，
・路線価 （今回の価格）
・固定資産評価額 （参考：総務省「固定資産税の概要」）
・公示価格 （参考：国土交通省「地価公示」）
・実勢価格 （査定の依頼など，例 国土交通省 「不動産情報ライブラリ」）
の４つの価格があります。（一物四価）
今回の路線価の主な使い道は，相続税と贈与税の算定です。
（国税庁「No.4602 土地家屋の評価」）
前年度分（令和５年度分）も閲覧できるため，ご自身のお持ちの土地を前年度と比較してみるのもいいのではないでしょうか。
故人の資産の保管場所を相続人に教えておかない場合も多いです。
集英社にデジタル資産の相続税の申告忘れの記事がありました。
参照 集英社オンライン：【現代の相続問題で一番気をつけるべきは「デジタル資産」。申告忘れには加算税や延滞税が上乗せされる…相続専門税理士が指摘する３つの問題点とは】
故人の資産のうち，デジタル資産や暗号資産を知らないところで探すということは，とてつもなく大変なことです。書面の取引であれば，四半期に１回程度，有価証券の取引履歴が証券会社や信託銀行から送付されてきたり，銀行の通帳があったりしますが，デジタル資産や暗号資産の場合には，契約から取引履歴まて，オンライン上で完結している場合も多く，すぐに探し出すというわけにはいきません。
（例 ＳＢＩ証券「電子交付」，松井証券「取引しましたが取引報告書等が送られてきません。」）
探すことに着手するにしても，金融機関数だけでも，１，３８２件程度。（２０２４年５月３１日現在 日本金融通信社：「最新の業態別金融機関数」）その中でもネット銀行にあたる，その他銀行だけでも１５行，証券会社で２７１法人も存在するため，調査するにもなかなかの労力と費用がかかります。
また，暗号資産取引所も３２社（２０２４年６月３日現在）あるそうです。（日本暗号資産取引業協会「統計情報」）
できれば，デジタル資産をお持ちのかたは，「エンディングノート」等（参考：長野地方法務局／長野県司法書士会「エンディングノートを作成しました」）を活用していただき，デジタル資産や暗号資産の口座の取引先を１年に１回程度記録しておいたほうがよいかと思います。
参考までに，暗号資産は，故人の相続人が請求しないと消滅時効にかかることもあります。（参考 日本暗号資産取引業協会：「暗号資産取引業における主要な経理処理例示」Ⅲ 経理処理等）その場合は，多額の暗号資産を喪失することもありますので，注意が必要です。
厳守されている法人も少なくはないようです。
毎年６月は，３月決算の会社の法人の総会が集中する時期であり，役員の変更も多くされる時期です。この役員変更の場合に行われるべき変更登記は，株式会社の場合，変更から２週間が登記の期限となっています。（会社法第９１５条第１項）
しかしながら，変更登記には役員の印鑑証明書や住民票等のそろえる書類も多く，取締役会議事録のように出席した役員全員の押印が必要な場合もあるため，２週間はかなりタイトなスケジュールといえます。
この期間を厳守される会社においては，その会社の従業員などが，議事録を持ち，役員のいる仕事先や住まい等をわざわざ回っておられる場合も多く，かなり苦労されている印象です。効率化のするため，今後はマイナンバーカードの電子署名等を用いて議事録をメール等のシステムで回覧する方法をする会社も増えてくるかもしれません。
実際はこの登記期間については法務局の運用でカバーされています。
（参考：法務省「役員の変更の登記を忘れていませんか？ 再任の方も必要です」）
法律条文上の２週間という期間については，もうちょっと余裕を持たせてほしいと願うばかりです。
戸籍のシステムで障害が相次いでいるようです。
（朝日新聞：「戸籍システムで障害3カ月、全国で影響 職員が電話で穴埋め」）
処理エラーが発生しているだけでなく，本籍地以外で出力した場合，データの更新漏れもあり，本籍地以外の自治体の職員が，本籍地の自治体に電話確認しているとのことです。
本籍地以外で戸籍謄本を取れるようになったことにより，利用者にとっては相続手続きに際して劇的に利便性が向上したので，今後戸籍システム自体の安定化により，戸籍謄本をスムーズに取得できるようになってほしいものです。
離婚後の共同親権を認めた場合，争いの種が増えるかもしれません。
離婚後の親権を父母共同で行うことが選択できる「共同親権」と子の監護に関する費用の先取特権に関する民法改正の法案が衆議院を可決しました。（民法等の一部を改正する法律案）
離婚後の親権は改正案においては，協議離婚の場合は離婚前に協議で「双方又は一方を親権者と定める」とし，裁判離婚の場合は，「父母の双方又は一方を親権者」に裁判所が定めるとしています。（改正案民法 第８１９条）
また，一般の先取特権の中に「子の監護の費用」が追加されています。（改正案民法 第３０６条第３号）
Windowsであっても，Linuxであっても文字を操作するプログラムには，文字コード変換が絡んでくる場合が多いです。
Windowsの場合は，以前のプログラムの文字コードがShift-JISのままになっており，最近ではUTF-8に変換する必要があります。
Fedoraにおいては，創生初期からUTF8を採用しており，特に問題にはならない場合が多いのですが，昔の資産であるbashコード等のプログラムを利用するため，system()やexec()を利用したときに変な現象に遭遇しました。
その現象とは，例えば以下のようなソースを，コマンドラインで直接実行した場合と，Web経由でPerl(CGI)とsystem()を利用してbashとして実行したときに全く別の結果が出ました。
#!/bin/bash
test=’長野県長野市’
echo ${test:0:3}bashやperl: 長野県
Apache経由CGI: 長
説明すると，通常は前から３文字目まで文字の切り出しをして表示するので，「長野県」と出力されるのが正しいところ，Web経由で「長」と出力するのみで文字化けのような状況になりました。
よく考えるとCGIの場合，漢字1文字で3バイトであるため，3バイト分しか表示していないことがわかります。
試しに以下の実行命令をしのばせておくと
locale
出力にOSからのコマンドラインやPerlからexec()やsystem()で実行した場合には，”ja_JP.UTF-8″と表示するにも関わらず，CGIから実行した場合には，”POSIX”を表示してしまいました。このままでは，コマンドラインとWeb環境では日本語処理が同じようにできない状態です。解決方法としては上記ソースの2行目に
export LANG=ja_JP.UTF-8
を挿入すれば，Apacheでも正常に文字の切り出しができることがわかりました。
本来はどうすればいいか調べると，どのサーバー環境の文字環境でも対応できるよう，POSIXに統一してソースを書いたほうがベストらしいので，
#!/bin/bash
export LANG=POSIX
test=’長野県長野市’
echo ${test:0:9}
とするほうが正しいのかも知れません。しかし，プログラムが長い場合，大量の文字数の書き換え等が必要となってしまいます。古い資産を使うという点では，system()やexec()の用いたときには，ソースを書き換えずには利用したいので，対処方法としては「export LANG=ja_JP.UTF-8」の1行を挿入するほうを選択しました。
UNIXやLinuxはすでに歴史が長くなってきているので，昔の人が作ったプログラムをそのまま実行したいというニーズも多いかと思いますので，参考にしてください。
以前Fedora39からFedora40に移行について，記事にしましたが，Webサーバーからのファイル出力やデバイスの制御ができなくなってしまい，かなり手を焼きました。
症状としては，Fedora39からFedora40にアップデートしてから，FAXサーバー（efax）と知識の整理に使っていた「YukiWiki」というウェブアプリケーションが使えなったことです。
eFAXは，受信も送信も使えなくなりましたが，送受信それぞれ原因は異なりました。FAXの送信ができない理由とYukiWikiが使えなくなった理由は一緒でした。
FAX受信のほうは，もともとtiff形式で受信するため，tiffをPDFに変換するソフトが必要で，今までは「tiff2pdf」を利用していましたが，Fedora40からバンドルされなくなったのが原因です。
これについては，他のツール「ImageMagick」のconvertというコマンドを使うことにして解決しました。
convertの使い方は
convert recivefax.000.tiff recivefax.001.tiff recivefax.pdf
というように，複数のtiffファイルを１冊のPDFにすることも可能なので比較的移行が簡単にできました。
FAX送信のほうはかなりたいへんでした。症状としては，httpd(Apacheサーバー)から，/home以下にファイルの出力ができなくなったことと，/dev/serial といったモデムデバイスにアクセスできなくなったことです。
例えば，次のcgiを作成してWebサーバー上からアクセスした場合，
open(DATAFILE, “> ./test.txt”) or die(“Error:$!”);
print DATAFILE “長野県\n”;
close(DATAFILE);
通常なら，cgiのあるディレクトリ上にtest.txtというファイルが作成され，長野県と文字が入力されますが，作成されず，エラーログを確認すると
[cgid:error] [pid xxxxxx:tid xxxxxx] [client ::1:xxxxx] AH01215: stderr from /home/hoge/test.cgi: Error:Read-only file system at /home/hoge/test.cgi line 1.
が「/var/log/httpd/error_log」上に出力されます。他にも，PukiWikiを実行して，テキストの書換えを行うと
AH01215: stderr from /home/hoge/test.cgi: Permission denied at /home/hoge/test.cgi line x.
や
AH01215: stderr from /home/hoge/wiki.cgi: [Fri May x xx:xx:xxx 2024] wiki.cgi: /home/home/hoge//diff/XXXXXXXXXXXXXXXXXXXX.txt cannot be created at Yuki/YukiWikiDB.pm line 84., referer:(略)
等，大体同じようなアクセス制御系のエラーが表示されました。
httpdのコンフィグやファイル，ディレクトリのアクセス権限等，いろいろあたってみましたが，全然解決せず，途中でFedoraフォーラムに問い合わせてみましたが，書いたあとにたまたまsystemdでhttpdのファイル制御している記事（Webuzo:「How to increase the number of open files allowed for Apache2」）を見つけて，自己解決できました。
理由は，どうやら，systemdの制御のコンフィグが変わったのが原因のようでした。解決の方法としては，
vim /usr/lib/systemd/system/httpd.service
以下追記
DeviceAllow=/dev/ttyS0 rwProtectHome=read-only
PrivateDevices=yes
↓
ProtectHome=false
PrivateDevices=no
に変更
のちに，
sudo systemctl daemon-reload
sudo systemctl restart httpd
を実行したらうまくいきました。/homeディレクトリと/devをsystemdでアクセスを制限していたようです。無事Fedora40でもefaxサーバーの運用ができるようになりました。
（”PrivateDevices=yes”と” sudo systemctl restart httpd”は，5/11追記 ）
