Transmission ошибка 401

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

« Последнее редактирование: 14 Июля 2019, 03:11:31 от zg_nico »

kononvaler

GreenFrog2

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

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

kononvaler

Имеются ли допонительные жесткие диски, кроме системного, монтируемые для торрентов?
Имею подозрение (у меня так бывает на домашнем сервере), что когда после перезагрузки компа  запаздывает монтирование дисков при старте демона трансмишн, он не стартует.
в следующий раз если не будет подключения через веб интерфейс, проверьте наличие запущенного сервиса например командой
ps -ef | grep transmission

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»
…………………………………
добавить выделенную строку, что должно дать задержку запуска трансмишена на минуту, и посмотрим на результат после перезагрузки.

« Последнее редактирование: 21 Сентября 2016, 21:04:29 от kononvaler »

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-ом?

« Последнее редактирование: 23 Сентября 2016, 09:43:42 от kononvaler »

GreenFrog2

Команду с grep cron попробовал, ничего не вывела.
Simple Backup настраиваю через GUI Simple Backup-configuration for admins. Там есть строка для настройки cron.
Раньше в версии ubuntu 4.04 работал. Сейчас перешел на 16.04 в связи с апгрейдом всего железа. И вот пожалуйста, игры в которые не играю идут, а необходимые программы нет.

Hey everyone!

I have installed transmission on my headless Ubuntu 8.04.1 server and am having troubles accessing the web GUI for it on the same network.

I have 1.42 installed (using transmissioncli -v):

Transmission 1.42 (7495) - http://www.transmissionbt.com/
No torrent specified!

When I try to access http://192.168.0.17:9091/ I get the following error:

401: Unauthorized

Unauthorized IP Address.

Either disable the IP address whitelist or add your address to it.

If you’re editing settings.json, see the ‘rpc-whitelist’ and ‘rpc-whitelist-enabled’ entries.

If you’re still using ACLs, use a whitelist instead. See the transmission-daemon manpage for details.

I went to my settings.json file and it looks like this:

{
    "blocklist-enabled": 0, 
    "download-dir": "/home/jamie", 
    "download-limit": 600, 
    "download-limit-enabled": 0, 
    "encryption": 1, 
    "max-peers-global": 200, 
    "peer-port": 51413, 
    "pex-enabled": 1, 
    "port-forwarding-enabled": 0, 
    "rpc-authentication-required": 0, 
    "rpc-password": "", 
    "rpc-port": 9091, 
    "rpc-username": "", 
    "rpc-whitelist": "127.0.0.1", 
    "upload-limit": 10, 
    "upload-limit-enabled": 0
}

I tried adding and changing the IP address in the «rpc-whitelist» to my Servers IP address and I still get the same error.

Is there a solution to this?

Any help will be great.

Waldorf wrote:Try setting the rpc-whitelist to «127.0.0.1,192.168.*.*».

I did do that and I still got the same message. Must the IP be the servers IP or the IP of the PC trying to connect to it?

You need to stop the daemon, change settings.json, then start the daemon.

And yes, the address(es) that go in there are the computers that you want to have access to the daemon (either using a Web browser or transmission-remote). The example Waldorf gave you means all your local network, since you showed your server as being 192.168.0.17, the LAN could be 192.168.0.* or if you have sub-LANs 192.168.*.*

Hi,

I am having the same problem, but that solution has not helped… Any ideas?

Thanks,

Jez

    "blocklist-enabled": 0,
    "download-dir": "/home/jez",
    "download-limit": 600,
    "download-limit-enabled": 0,
    "encryption": 1,
    "max-peers-global": 200,
    "peer-port": 16868,
    "pex-enabled": 1,
    "port-forwarding-enabled": 0,
    "rpc-authentication-required": 0,
    "rpc-password": "",
    "rpc-port": 9091,
    "rpc-username": "jez",
    "rpc-whitelist": "127.0.0.1,192.168.*.*,192.168.1.65"
    "upload-limit": 5,
    "upload-limit-enabled": 0

rb07 wrote:You need to stop the daemon, change settings.json, then start the daemon.

And yes, the address(es) that go in there are the computers that you want to have access to the daemon (either using a Web browser or transmission-remote). The example Waldorf gave you means all your local network, since you showed your server as being 192.168.0.17, the LAN could be 192.168.0.* or if you have sub-LANs 192.168.*.*

Okay I did that and I still get the same error message:

{
    "blocklist-enabled": 0, 
    "download-dir": "/media/store/torrents", 
    "download-limit": 100, 
    "download-limit-enabled": 0, 
    "encryption": 1, 
    "max-peers-global": 200, 
    "peer-port": 51413, 
    "pex-enabled": 1, 
    "port-forwarding-enabled": 0, 
    "rpc-authentication-required": 0, 
    "rpc-password": "", 
    "rpc-port": 9091, 
    "rpc-username": "",
    "rpc-whitelist": "127.0.0.1,192.168.0.4", 
    "upload-limit": 10, 
    "upload-limit-enabled": 1
}

192.168.0.4 is the IP address of the Vista PC trying to access the web GUI. It still is coming up with the same error message.

How do I properly stop and start the daemon?

OK, actually the answer was not complete.

There are 3 ways to make the daemon use a whitelist:

• Using a parameter when starting the daemon (i.e. -a 127.0.0.1,192.168.0.1);
• Adding/changing the rpc-whitelist line to settings.json;
• the default which is: only 127.0.0.1 has access, by not using one or both of the previous ways.

Since in your first message you showed what seems to be the result of the default way, we assumed you were not using the first way. If the daemon is started with ‘-a 127.0.0.1’ it will behave as before but also, when shut-down, it will overwrite settings.json and the rpc-whitelist will show only 127.0.0.1 .

You could test if the running daemon is using that default whitelist by running on your headless server ‘transmission-remote -l’.

Also you can check if the daemon really stopped by using the usual tools: ‘pgrep -l trans’ or ‘ps -ef | grep trans’; looking at the timestamp on settings.json could be another way (I’m not sure if the file is overwritten when nothing changed).

rb07 wrote:OK, actually the answer was not complete.

There are 3 ways to make the daemon use a whitelist:

• Using a parameter when starting the daemon (i.e. -a 127.0.0.1,192.168.0.1);
• Adding/changing the rpc-whitelist line to settings.json;
• the default which is: only 127.0.0.1 has access, by not using one or both of the previous ways.

Since in your first message you showed what seems to be the result of the default way, we assumed you were not using the first way. If the daemon is started with ‘-a 127.0.0.1’ it will behave as before but also, when shut-down, it will overwrite settings.json and the rpc-whitelist will show only 127.0.0.1 .

You could test if the running daemon is using that default whitelist by running on your headless server ‘transmission-remote -l’.

Also you can check if the daemon really stopped by using the usual tools: ‘pgrep -l trans’ or ‘ps -ef | grep trans’; looking at the timestamp on settings.json could be another way (I’m not sure if the file is overwritten when nothing changed).

Okay here is what shows when I type in the following:

‘transmission-remote -l’:

ID    Done  ETA       Up      Down    Ratio  Status       Name

‘pgrep -l trans’:

4674 transmission-da
4729 transmission-da
5397 transmission-da
7165 transmission-da
11880 transmission-da

Hmm, not sure what to make of these.

The transmission-remote output is OK, you have no torrents but it shows that the daemon did not complain.

The pgrep output shows that you have 5 daemons running… that’s the problem, in fact it probably shows a big bug on the daemon: why it doesn’t complain that the first daemon has control over the peer and control ports?

Anyway, I had a similar problem with Gentoo, that’s why I started writing the init.d script and configuring things better, in my case the /etc/init.d/transmission (in Gentoo it was named transmission-daemon) script was assuming that the daemon uses a pid file (what other servers put in /var/run/), it doesn’t, and when it tries to stop the daemon it doesn’t find a pid-file so the script didn’t do a thing.

First you have to kill those daemons (masacre in this case), yep ‘kill 4671 4729 5397 7165 11880’ all of them.

Then you’ll have to review the script and see what’s wrong with it.

rb07 wrote:The transmission-remote output is OK, you have no torrents but it shows that the daemon did not complain.

The pgrep output shows that you have 5 daemons running… that’s the problem, in fact it probably shows a big bug on the daemon: why it doesn’t complain that the first daemon has control over the peer and control ports?

Anyway, I had a similar problem with Gentoo, that’s why I started writing the init.d script and configuring things better, in my case the /etc/init.d/transmission (in Gentoo it was named transmission-daemon) script was assuming that the daemon uses a pid file (what other servers put in /var/run/), it doesn’t, and when it tries to stop the daemon it doesn’t find a pid-file so the script didn’t do a thing.

First you have to kill those daemons (masacre in this case), yep ‘kill 4671 4729 5397 7165 11880’ all of them.

Then you’ll have to review the script and see what’s wrong with it.

Thanks for all the help rb07. I will do that and report back.

rb07 wrote:OK, actually the answer was not complete.

There are 3 ways to make the daemon use a whitelist:

• Using a parameter when starting the daemon (i.e. -a 127.0.0.1,192.168.0.1);
• Adding/changing the rpc-whitelist line to settings.json;
• the default which is: only 127.0.0.1 has access, by not using one or both of the previous ways.

Since in your first message you showed what seems to be the result of the default way, we assumed you were not using the first way. If the daemon is started with ‘-a 127.0.0.1’ it will behave as before but also, when shut-down, it will overwrite settings.json and the rpc-whitelist will show only 127.0.0.1 .

You could test if the running daemon is using that default whitelist by running on your headless server ‘transmission-remote -l’.

Also you can check if the daemon really stopped by using the usual tools: ‘pgrep -l trans’ or ‘ps -ef | grep trans’; looking at the timestamp on settings.json could be another way (I’m not sure if the file is overwritten when nothing changed).

hello,

i’ve been using transmission on my openwrt box (Asus WL-500GP) and recently compiled last version 1.42 (7495) and give it a try.
what i don’t understant or i don’t get the ideea behind it, is the whitelist and the transmission-daemon not starting the webif!

1.
{
…
«rpc-whitelist-enabled»: 0,
…
}

if i put this option in settings.json to FALSE, the whitelist should be disabled, right?
here is the output:

root@wl500gp:~# transmission-daemon -f
Transmission 1.42 (7495) started
RPC Server: Adding address to whitelist: 127.0.0.1
RPC Server: Serving RPC and Web requests on port 9091
RPC Server: Whitelist enabled <-- wtf??
Port Forwarding: Opened port 51413 to listen for incoming peer connections

2.
if i start transmission-daemon it starts without the embeded web server.
if i start transmission-daemon -f it starts, in foreground, with the embeded server started.

really, i don’t get it!

so it was working (sid). i have done a few upgrades without actually needing to go into the webgui

i don’t seem to see my settings have changed

    "rpc-authentication-required": true,
    "rpc-bind-address": "0.0.0.0",
    "rpc-enabled": true,
    "rpc-host-whitelist": "",
    "rpc-host-whitelist-enabled": true,
    "rpc-password": "password",
    "rpc-port": 9091,
    "rpc-url": "/transmission/",
    "rpc-username": "transmission",
    "rpc-whitelist": "127.0.0.1,192.168.*.*",
    "rpc-whitelist-enabled": true,

i try access http://192.168.0.102:9091/transmission/web/ (which i was previously able to) and get

401: Unauthorized
Unauthorized User. 1 unsuccessful login attempts.

the daemon is actually working and is downloading things as it should.

installed packages
# dpkg -l | grep transmission

ii  transmission-cli                                            3.00-1                                        amd64        lightweight BitTorrent client (command line programs)
ii  transmission-common                                         3.00-1                                        all          lightweight BitTorrent client (common files)
ii  transmission-daemon                                         3.00-1                                        amd64        lightweight BitTorrent client (daemon)
ii  transmission-gtk                                            3.00-1                                        amd64        lightweight BitTorrent client (GTK+ interface)

what am i missing here?

oh this is a remote server i am trying to access