Проблемы с разрешениями для Transmission daemon и не только

Продолжаю настраивать свой домашний NAS и сгребать грабли.
Настроив SAMBA и получив весьма приличный результат по скорости копирования (>90МиБ/с), решил поставить и настроить Transmission daemon - чтоб NAS спокойно качал торренты, а пользователи могли ставить на закачку файлы через Transmission remote GUI, работающий, как с компов, так и с мобилок.

В общем, настройка Transmission daemon - не бог весть какая сложность - редактируешь себе /etc/ transmission daemon/settings.json , добавляешь нужных пользователей в группу transmission (в случае с Debian - это debian transmission), даёшь разрешения на нужные папки этому самому пользователю от которого работает transmission daemon (его можно проверить в конфиге /etc/init.d/transmission-daemon в разделе USER и, казалось бы, дело в шляпе.

Не тут то было. Всё сделал - при попытке скачать torrent получаю ошибку Permission denied.
Лезу, смотрю, что там с папкой:

$ls -l /share/HDB/Download 

Вижу ответ: drwxrwxrwx+ и по невнимательности своей думаю - ну всё ок вроде. Даю права владельца пользователю transmission - начало качать.
Вот только нафига нужны все файлы в одной свалке в "Download"? Не нужны - нужно перемешать в папки Video, Music и т.д. А там - такая же засада.

В общем, долго я мучился, пока не обнаружил тот самый идиотский "+" на конце. Оказывается, жолбаный QNAP, в чьём ведении до этого был жёсткий диск, умудрился проставить всем папкам и файлам ACL разрешения. А они ведь такая зараза, что перекрывают обычные nix'овые. Там и пользователи конкретные могут быть вписаны, и маски заданы.

В общем, снёс нахрен все ACL'ы с этих папок командой:

#setfacl -Rb /share/

Проблема разрешилась - transmission пишет во все нужные папки - жизнь удалась.

BTRFS is not so better

 Уже старая, вовремя не запощенная запись по BTRFS, родившаяся, как комент на хабрахабре про то, какая хорошая и перспективная файловая система этот бэтэрэфэс.
Оставлю тут в качестве предостережения. Уж поверьте, я с этой системой достаточно намаялся, чтобы предпочитать ей кривоватую связку ext4+LVM, для реализации некоторого функционала, не доступного в старых файловых системах.

Касательно btrfs, может у Facebook'а с его армией программистов низкого уровня и живёт это как-то, но мне кажутся полными камикадзами те, кто пытаются тащить в продакшн файловую систему к которой физически не существует полноценного инструментария для восстановления, с единственным аргументом «да она практически не ломается»… Ломается и ещё как ломается.

И даже не обязательно до потери данных, есть, например такие ошибки, когда найдены чексумы на не существующие данные и инструменты не позволяют изменять файловую систему (отрубаются все возможности по shrink, работе с субтомами и т.д.) и сделать можно ровным счётом ни-че-го. Только бэкап данных --> снос раздела --> восстановление данных на вновь созданный раздел.

И коллектив разработчиков из «гениев», которые лепят ошибки, делают неполноценные фичи, ломающие работающий функционал и потом отмазывающиеся ответами типа «а ну это у нас в версии такой-то баг был, что у вас всё слетело кхерям, но уже исправили» или «ах, а мы и не знали, что новая фича ломает старую». И ладно бы эти косяки попадали только в unstable — в обычном ubuntu со стабильными ядрами такое возникает регулярно — просто потому, что, оказывается, вот таким вот специфическим функционалом файловой системы не многие пользуются и не отловили.

Отсутствие документации на функции и вообще невнятность работы некоторых функций тоже доставляют. До ядра 3.17 при исполнении btrfs check --init-csum-tree с описанием мол «перестраивает дерево чексумм», на деле просто сносило к чёрту дерево чексум и делало файловую систему не читаемой. Потом кто-то в мэйллисте на это тыкнул с вопросом «а нахрена это надо?» И получил ответ типа «а ну не нужно ей пользоваться она ещё не дописана, чтоб реально работала». А добавили так, просто, как кнопку «харакири», только под надписью «реанимация».

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

Ubuntu Server 16.04 LTS Застряла в перезагрузке

Давича решил соорудить из дешёвого ПК, маленький домашний сервер и столкнулся с проблемой - сразу после установки Ubuntu Server 16.04 впал в цикл бесконечной перезагрузки.

Причём вход в Recovery происходил нормально и если врубить пункт продолжения загрузки - всё вроде как грузилось. Изучение journalctl дало единственную наводку - ошибка с radeon drm.
Я так слегка прифигел, от того, что на серверной оси пытается грузиться графика, решил посмотреть, что там в целях загрузки у GRUB стоит и обнаружил:

$sudo systemctl get-default

graphical.target 

Исправил это дело на multiuser.target:

$sudo systemctl set-default multiuser.target

Перезагрузился и... нифига - всё так же.
Снова попал в систему через рекавери, и начал гуглить.
Наткнулся на другую проблему на Ask Ubuntu.
Решил проверить настройки GRUB и обнаружил строку:

GRUB_CMDLINE_LINUX_DEFAULT=""

Заполнив пространство между "" параметром "nomodeset" и обновив груб ($sudo update-grub) получил реальную загрузку в текстовом режиме и проблема решилась!

В общем, чтоб не забыть решение - оставлю тут.