Transmission remote gui ошибка подключения

Прошу прощения как новичок, если тема заезжена, но чесслово, не нашел ответа. Итак, проблема (помогаю дочке): медиаплеер ASUS O!Play HDP-3R, подключен по Wi-Fi к интернету через роутер Netgear N150. В домашней сети имеет адрес 192.168.1.4. На плеер установил пакет MoServices как описано здесь на сайте через ноутбук, в свою очередь, на котором я установил прогу Transmission Remote GUI. В составе пакета запущен бит-торрент клиент Transmission. Так вот, проблема в управлении Transmission с помощью Transmission GUI Remote. Нифига не подключается. В инструкции написаны логин и пароль веб-интерфейса login: torrent, pwd: 1234. Создаю соединение в программе Transmission Remote GUI с адресом

http://192.168.1.4

, логином и паролем — отказ в соединении. Причем если адрес указать именно как

http://

<…>, то сообщение host not found, если же просто 192.168.1.4, то connection refused. Попытки обнулить логин и пароль ничего не дают. В то же время если в интернет-эксплорере тупо вбить 192.168.1.4, то ноут отлично соединяется с медиаплеером, появляется некий графический интерфейс, в котором есть пункт меню bittorrent client, тыкая в который вызывается некая управлялка к нему, позволяющая создавать закачки. И все работает. Но управлялка бедноватая, опять-таки она отлична по виду от привычного uTorrent клиента, что для дочки очень критично (мне-то наплевать). Хотелось бы прикрутить Transmission Remote GUI. Что я делаю не так? Я в общем-то знаю, что Transmission имеет ограничения по удаленному управлению, но штука в том, что обычные описания 127.0.01, 192.168.*.* должно вполне устраивать — ноут именно адрес такого вида имеет в домашней сети (192.168.1.2 или .3 — сейчас точно не помню). Т.е. по идее стандартная маска вполне должна подходить. Насчет проброски портов — пока порт 9091 в роутере не пробрасывал, но ПМСМ это не особо и нужно — обычным-то веб-интерфейсом от интернет-эксплорера Transmission управляется, причем по умолчанию именно через порт 9091. Еще раз прошу извинить, если тема знакомая.

первый раз такое услышал. Если из браузера

http://192.168.1.4:9091

доступен, то и Remote GUI должен работать.
На всякий случай скиньте конфиг трансмишена сюда.

Если честно, я официальную прошивку снёс последний раз полтора года назад По поводу вайфай — имхо баловство это — драйвера под реалтековский чип, который стоит у вас зело кривые и выпрямлять их никто не собирается.
Да и скорости по вафле не хватает для более-менее серьёзных потоков. Мой вам совет — не поленитесь, прокиньте провод.
тема moServices3 —

viewtopic.php?f=16&t=694

тема альтернативных прошивок —

viewtopic.php?f=8&t=1029

ФАК по прошивке плеера —

viewforum.php?f=21

GreenFrog2

Добрый вечер!

Установил и настроил transmission-daemon под Ubuntu 16.04 согласно этим рекомендациям. В веб-морду по адресу http://localhost:9091/ не заходит.Просто крутит значек загрузки страницы. Transmission Remote GUI при подключении выдает ошибку 401: Unauthorized Unauthorized User.
Вот эту тему читал. Изменение пользователя в файле пользователя в файле /etc/systemd/system/multi-user.target.wants/transmission-daemon.service не помогло.
Прошу подсказать в чем моя ошибка.

С уважением,
GreenFrog2.

ТС не появлялся на Форуме более полугода по состоянию на 14/07/2019 (последняя явка: 05/09/2018). Модератором раздела принято решение закрыть тему.
—zg_nico

kononvaler

Посмотрите что говороит при перезапуске сервиса:
sudo service transmission-daemon restart
настроики у меня обычно такие (запуск демона от пользователя, которому принадлежат директории хранения. чтобы права на файлы и директории не путались)
и конфиг смещаю в хоум:

GreenFrog2

Доброе утро, kononvaler!
После рестарта сервиса указанной командой все заработало. И веб морда и Transmission Remote GUI.
Странно, не понял причину успеха. Я когда эксперементировал с настройками всегда останавливал сервис, потом запускал. Изменения должны были сработать.

С уважением,
Зеленая лягушка.

kononvaler

GreenFrog2

Всем спасибо!
Все заработало после команды

sudo service transmission-daemon restart

Имеются ли допонительные жесткие диски, кроме системного, монтируемые для торрентов?

Да, Система / и /homе стоят на одном физическом диске, а сами торренты расположены на другом физическом диске ext4, мотируемом автоматически при запуске командой из файла /etc/fstab

Если не будет подключения, проверю указанной командой.

С уважением,
Зеленая лягушка.

GreenFrog2

kononvaler, добрый вечер!
В продолжение темы хочу обсудить еще такую проблему.
При перезагрузке компьютера GUI выдает ошибку Connection refused.
По команде

ps -ef | grep transmission
вывод такой

greenfr+  2415  2228  0 20:31 pts/4    00:00:00 grep --color=auto transmissionЭто сервис не успевает стартовать или другое?
По команде

sudo service transmission-daemon restartвсе работает нормально.

С уважением,
Зеленая лягушка.

kononvaler

вывод такой
Код: [Выделить]

greenfr+  2415  2228  0 20:31 pts/4    00:00:00 grep —color=auto transmission

это значит что сервис не стартанутый, вывод который мы видим выше это сэлфи нашего запроса.
если бы сервис был запущен, то увидели бы два результата:
valery    8173     1  0 сент.11 ?  02:06:23 /usr/bin/transmission-daemon -f —config-dir /home/valery/.config/transmission/
valery   29065 29016  0 23:53 pts/3    00:00:00 grep —color=auto transmission
первый сам демон, второе как уже обсудили на вашем примере.
Мое предположение, что сервис пытается стартовать и падает до того как смонтируется диск с нужным ресурсом.
Я попробовал добавить в скрипт запуска задержку, но еще ни разу не перегружался (у меня сервер в подвале невыключаемый)
давайте попробуем сделать так:
sudo nano /etc/init.d/transmission-daemon
……………………………………………….
#!/bin/sh -e
### BEGIN INIT INFO
# Provides:          transmission-daemon
# Required-Start:    $local_fs $remote_fs $network
# Required-Stop:     $local_fs $remote_fs $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start or stop the transmission-daemon.
# Description:       Enable service provided by transmission-daemon.
### END INIT INFO

NAME=transmission-daemon
DAEMON=/usr/bin/$NAME
USER=valery
STOP_TIMEOUT=30

sleep 60s

export PATH=»${PATH:+$PATH:}/sbin»
…………………………………
добавить выделенную строку, что должно дать задержку запуска трансмишена на минуту, и посмотрим на результат после перезагрузки.

GreenFrog2

kononvaler, внес исправления, перезагрузился.
вывод команды тот же

greenfr+  2525  2511  0 22:20 pts/1    00:00:00 grep --color=auto transmission

kononvaler

давайте включим лог и посмотрим, будет ли что-то туда записано:
/etc/default/transmission-daemon

# Default options for daemon, see transmission-daemon(1) for more options
OPTIONS=»—config-dir $CONFIG_DIR —logfile /path_to/transmission.log«

GreenFrog2

kononvaler, добрый вечер!

В указанном файле добавил строку

OPTIONS="--config-dir $CONFIG_DIR --logfile /home/greenfrog/log/transmission.log"Перезагрузился. Лог файл не появился.

Похожая ерунда с Simple Backup. Установил из менеджера приложений, настроил. Расписние задал в формате cron 0 0 3 * *
Задал вывод лога. Ничего не происходит. Архив не создает, лог не пишет.

С уважением,
Зеленая лягушка.

Dot-mitsu

У меня помню была подобная проблемка давно ещё, но я не стал её решать потому что мне на сервере нужна была gui версия трансмишена. GUI версия нормально работает и запускается после перезагрузки автоматически без проблем.

kononvaler

от какого пользователя запускается даемон? у него есть доступ к указанной директории? в syslog есть что-нибудь про трансмишн?
sudo tail -n 100 /var/log/syslog |grep transmission
у меня на сервере через kodi по hdmi подключен телек, пультом ComPro K300 все это управляется, еще Plex по сети раздает, еще Owncloud работает, потому просто не доберусь проэксперементировать, так что давайте у вас домучаем причину.

Пользователь добавил сообщение 23 Сентября 2016, 05:26:00:

У меня помню была подобная проблемка давно ещё, но я не стал её решать потому что мне на сервере нужна была gui версия трансмишена. GUI версия нормально работает и запускается после перезагрузки автоматически без проблем.

То что вы называете гуи версией, это пользовательский локальный трансмишн, он не запускается автоматически, а вы его стартуете из меню. Сдесь тоже все работает при ручном перезапуске, но нет автстарта при старте системы.

« Последнее редактирование: 23 Сентября 2016, 05:26:01 от kononvaler »

GreenFrog2

Демон запускается от моего пользовательского имени — greenfrog. В первом посте я давал ссылку на настроийки, согласно которым все запускается от моего имени, что бы у меня был доступ к файлам, скачанным демоном.
Права на папку log: владелец — текущий пользователь (создание и удаление файлов); группа — greenfrog (создание и удаление файлов).
Ввел в термилале указанную команду, она ничего не вывела. Открыл syslog руками. Вот его содержание

Sep 23 07:36:18 greenfrog-System-Product-Name anacron[7568]: Job `cron.daily' terminated
Sep 23 07:36:18 greenfrog-System-Product-Name anacron[7568]: Normal exit (1 job run)
Sep 23 08:10:25 greenfrog-System-Product-Name gnome-session[1635]: Nautilus-Share-Message: Called "net usershare info" but it failed: Не удалось выполнить процесс-потомок «net» (Нет такого файла или каталога)
Sep 23 08:15:41 greenfrog-System-Product-Name gnome-session[1635]: Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Sep 23 08:15:51 greenfrog-System-Product-Name gnome-session[1635]: Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Sep 23 08:17:01 greenfrog-System-Product-Name CRON[8342]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Sep 23 08:18:13 greenfrog-System-Product-Name gnome-session[1635]: Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Теперь понятно почему у меня Simple Backup не работает, но не понятно почему cron умирает.

kononvaler

Поставил 14.04 в виртуалку, поставил трансмишн-демон, перевел пользователя на себя, указал директорию сохранения на сетевой NFS ресурс, сделал его недоступным:
все отлично СТАРТУЕТ после перезагрузки, при попытке скачивания ругается на недоступность каталога.
Причина в чем-то другом, не в подключении дисков, надо читать про апстарт и где увидеть следы ошибки.

Ввел в термилале указанную команду, она ничего не вывела.

Ну так потому что нету ничего связанного с нашим демоном. Попробуйте так-же но с     grep cron  и получите все с ним связанные ошибки
И, кстати, ваш Simple Backup, не завязан на GUI ли, вы учли это в запуске cron-ом?

GreenFrog2

I’m getting connection refused with the Remote GUI although my Transmission settings file has not changed from earlier, when it worked fine.

Here output of ps aux | grep transmission-daemon:

pi       15534  0.0  0.4   3548  1836 pts/0    S+   16:40   0:00 grep --color=to transmission-daemon

To confirm the daemon should be running fine on the RPi.

settings.json file:

{
    "alt-speed-down": 50,
    "alt-speed-enabled": false,
    "alt-speed-time-begin": 540,
    "alt-speed-time-day": 127,
    "alt-speed-time-enabled": false,
    "alt-speed-time-end": 1020,
    "alt-speed-up": 5,
    "bind-address-ipv4": "0.0.0.0",
    "bind-address-ipv6": "::",
    "blocklist-enabled": true,
    "blocklist-url": "http://url"
    "cache-size-mb": 4,
    "dht-enabled": true,
    "download-dir": "/mnt/usbdrive/torrent/done",
    "download-limit": 100,
    "download-limit-enabled": 0,
    "download-queue-enabled": true,
    "download-queue-size": 15,
    "encryption": 1,
    "idle-seeding-limit": 30,
    "idle-seeding-limit-enabled": false,
    "incomplete-dir": "/mnt/usbdrive/torrent/temp",
    "incomplete-dir-enabled": true,
    "lpd-enabled": false,
    "max-peers-global": 200,
    "message-level": 2,
    "peer-congestion-algorithm": "",
    "peer-limit-global": 240,
    "peer-limit-per-torrent": 30,
    "peer-port": 51413,
    "peer-port-random-high": 65535,
    "peer-port-random-low": 49152,
    "peer-port-random-on-start": false,
    "peer-socket-tos": "default",
    "pex-enabled": true,
    "port-forwarding-enabled": true,
    "preallocation": 1,
    "prefetch-enabled": 1,
    "queue-stalled-enabled": true,
    "queue-stalled-minutes": 30,
    "ratio-limit": 2,
    "ratio-limit-enabled": false,
    "rename-partial-files": true,
    "rpc-authentication-required": false,
    "rpc-bind-address": "0.0.0.0",
    "rpc-enabled": true,
    "rpc-password": "password",
    "rpc-port": 9091,
    "rpc-url": "/transmission/",
    "rpc-username": "admin",
    "rpc-whitelist": "127.0.0.1,192.168.2.*",
    "rpc-whitelist-enabled": false,
    "scrape-paused-torrents-enabled": false,
    "script-torrent-done-enabled": false,
    "script-torrent-done-filename": "",
    "seed-queue-enabled": true,
    "seed-queue-size": 2,
    "speed-limit-down": 100,
    "speed-limit-down-enabled": false,
    "speed-limit-up": 100,
    "speed-limit-up-enabled": false,
    "start-added-torrents": false,
    "trash-original-torrent-files": false,
    "umask": 18,
    "upload-limit": 100,
    "upload-limit-enabled": 0,
    "upload-slots-per-torrent": 2,
  "utp-enabled": true,
    "watch-dir": "/mnt/usbdrive/torrent/watch",
    "watch-dir-enabled": true
}

I used to require RPC authentication and use an RPC whitelist, but I disabled both for testing, but that doesn’t help with the connection issue.

After research and googling, I’m suspecting it is due to folder permissions: I detached my USB drive on Raspberry Pi which is running Transmission Daemon as a service, and after reattaching the Remote GUI can’t connect. Could this be it?

Here permissions on the torrent temp folder:

drwxrwxrwx  37 root debian-transmission   4096 Jan  1 13:50 temp

This is the output of sudo netstat -tanp:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:49632           0.0.0.0:*               LISTEN      2842/btsync-daemon
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      5945/smbd
tcp        0      0 0.0.0.0:6000            0.0.0.0:*               LISTEN      3372/X
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      4321/sshd
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      2842/btsync-daemon
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      5945/smbd
tcp        0      0 192.168.2.48:445        192.168.2.18:40300      ESTABLISHED 6816/smbd
tcp        0      0 192.168.2.48:139        192.168.2.18:42347      ESTABLISHED 6298/smbd
tcp        0      0 192.168.2.48:22         192.168.2.18:44234      ESTABLISHED 12845/sshd: pi [pri

If I understand correctly, Transmission Daemon should be on this list as listening on 9091, but it’s not. So something is wrong.

My settings.json states that it should be listening on 9091, so not sure how to proceed with troubleshooting?

I re-installed the daemon, but I still get connection refused

I noticed that the two bind address fields below are both 0.0.0.0. Is this an issue? I tried changing them to the IP of the Raspberry Pi Transmission is running on, but I still can’t connect.

    "bind-address-ipv4": "0.0.0.0",
    "rpc-bind-address": "0.0.0.0",

The new install settings.json had «port-forwarding-enabled» set as false, and when I set it as true now I was finally able to connect, and everything is working fine!

the bind addresses are both 0.0.0.0 in the working settings.json file, so that wasn’t it.

So re-installing fixed it, and still don’t know what went wrong with the initial install.

And back, still talking to myself.

I’m unable to reconnect again, with the same settings.json file (below) which worked just a while ago

So there’s something outside Transmission which is intermittently messing things up. I’m able to connect to the RPi using samba file transfer, PuTTY and rsync, but Transmission Remote GUI gives Connection Refused error even when I have RPC whitelist and authentication disabled.

I’m at my wit’s end. Anyone have any ideas?

{
    "alt-speed-down": 50,
    "alt-speed-enabled": false,
    "alt-speed-time-begin": 540,
    "alt-speed-time-day": 127,
    "alt-speed-time-enabled": false,
    "alt-speed-time-end": 1020,
    "alt-speed-up": 5,
    "bind-address-ipv4": "0.0.0.0",
    "bind-address-ipv6": "::",
    "blocklist-enabled": true,
    "blocklist-url": "http://[url]",
    "cache-size-mb": 4,
    "dht-enabled": true,
    "download-dir": "[location]",
    "download-limit": 100,
    "download-limit-enabled": 0,
    "download-queue-enabled": true,
    "download-queue-size": 15,
    "encryption": 1,
    "idle-seeding-limit": 30,
    "idle-seeding-limit-enabled": false,
    "incomplete-dir": "[location]",
    "incomplete-dir-enabled": true,
    "lpd-enabled": false,
    "max-peers-global": 200,
    "message-level": 2,
    "peer-congestion-algorithm": "",
    "peer-limit-global": 240,
    "peer-limit-per-torrent": 30,
    "peer-port": 51413,
    "peer-port-random-high": 65535,
    "peer-port-random-low": 49152,
    "peer-port-random-on-start": false,
    "peer-socket-tos": "default",
    "pex-enabled": true,
    "port-forwarding-enabled": true,
    "preallocation": 1,
    "prefetch-enabled": 1,
    "queue-stalled-enabled": true,
    "queue-stalled-minutes": 30,
    "ratio-limit": 2,
    "ratio-limit-enabled": false,
    "rename-partial-files": true,
    "rpc-authentication-required": false,
    "rpc-bind-address": "0.0.0.0",
    "rpc-enabled": true,
    "rpc-password": "[password]",
    "rpc-port": 9091,
    "rpc-url": "/transmission/",
    "rpc-username": "admin",
    "rpc-whitelist": "*.*.*.*",
    "rpc-whitelist-enabled": false,
    "scrape-paused-torrents-enabled": false,
    "script-torrent-done-enabled": false,
    "script-torrent-done-filename": "",
    "seed-queue-enabled": true,
    "seed-queue-size": 2,
    "speed-limit-down": 100,
    "speed-limit-down-enabled": false,
    "speed-limit-up": 100,
    "speed-limit-up-enabled": false,
    "start-added-torrents": false,
    "trash-original-torrent-files": false,
    "umask": 18,
    "upload-limit": 100,
    "upload-limit-enabled": 0,
    "upload-slots-per-torrent": 2,
    "utp-enabled": true,
    "watch-dir": "[location]",
    "watch-dir-enabled": true
}

By almost an accident I noticed that the daemon shuts down or crashes shortly after starting it. After I run sudo service transmission-daemon reload/restart pair of commands, or just start it with start it reports OK. Running the same command with status shortly afterwards says OK as well. I can also confirm the service is running with ps ax.

But only a minute later, status says FAIL (Transmission not running) and ps ax doesn’t report anything on transmission!

Yet another round of uninstalling and re-installing from scratch. I went through each step to catch where everything breaks apart. RPC whitelist and authentication disabled, was able to connect with remote and web GUI. Enabled and set whitelist, and enabled authentication, reload and restart, still works. Then I copied my old torrents files from my previous installation, still working.

Finally, I copy my resume folder as well. And now it stops working! After I reload and restart the daemon, I’m unable to connect, and running ps ax confirms the daemon has shut down or has crashed. Testing it again, it crashes after roughly 10 seconds.

I delete the resume folder again, and remote access is back to functional. So something in the resume folder is messing things up!

Thought it was a permissions or file or group ownership issue, but that wasn’t it — at least changing them to pi:debian-transmission didn’t help.

Long story long: as I couldn’t figure out what in the resume folder was breaking things, I ended up deleting the resume folder. It turns out Transmission will create that folder with entries for all the torrents loaded. I’m currently running verification on the incomplete torrents and it recognizes the existence of previous incomplete files, and everything seems to be fine.

Took only several hours over several days… What a mess.

TLDR: in my case the original issue of being unable to connect is still unresolved. My suspicion is that apt-get upgrade broke something.

After reinstalling transmission-daemon, I could add earlier torrents to it, but adding the old resume folder broke Transmission. Therefore I deleted the resume folder, and ran verify on all existing torrents, ensuring that the temp folder location points to the location of the temp files. Now I’m getting all my previous incomplete torrents to resume, and all my earlier unstarted torrents to run.