loloed И что Вы хотите? Для ОС это ДВА разных пользовательских сеанса, каждый со своим системным окружением и различными правами доступа, потому ОС их вполне естественно изолирует.
Демоны (сервисы) проектируются как модули ОС работавшие в режиме ядра, а поэтому для полноценной работы им необходимы права доступа не ниже, чем у породившей их процесс задачи, данном случае нужны права учётной записи LOCAL SYSTEM. В противном случае гарантировать их правильную работу нельзя.
У Вас получается очень простая картина - пользователь от имени которого запущен демон имеет некий набор прав, но демон работает в его изолированном сеансе, а второй пользователь входит в систему в новом. А в том сеансе при построении набора сервисных функций демон запущенный от имени пользователя в список их поставщиков не попадает, но для демона задана учётная запись, и если он в данном сеансе не запущен, то в нём запускается его новая копия от имени той учётной записи, но в следствии блокировки по записи доступа к настройкам в конфигах она не может их прочитать, и запускается с временным, и понятное дело пустым конфигом.
Думаю, что так Вы сможете представить то, что у Вас получилось и увидеть почему в Вашем случае возникает ошибка.
Исправить её можно и вручную, но для этого надо выйти в консоль SCM (Service Control Manager) остановить и удалить в нём неверно установленный демон, перезапустить ОС, и с помощью SCM поставить его заново но уже от имени ОС.
Готовы возится? Пароль учётной записи LOCAL SYSTEM который запросит SCM знаете? Правда это можно сделать иными инструментами, но всё равно нужно точно понимать что Вы хотите добоится и как на Ваши команды отреагирует система. Если готовы, то я могу назвать Вам нужные инструменты и последовательность команд. Хотя, думаю Вам на первых порах будет проще деинталлировать сервер и установить его так, чтобы демон запускался от имени операционной системы. Тогда у Вас всё будет работать.
romalex88 Попробуйте увеличить в клиенте тайм-аут ожидания ответа сервера до 90 -120 секунд и включить режим поддержания соединения для данного сервера. Похожая ошибка была в первых версиях FarNetBOX 1.хх (использовал код Failezilla 2.хх) и причиной был именно малый тайм-аут до принятия FileZilla решения о том, что сервер не отвечает. По умолчанию там стояло 15 секунд, после изменения умолчаний на 90 секунд проблема ушла.
P.S. Цитата: Подробнее...[?]
Не загляни я
туда под море не и понял бы что Вам нужна помощь. У Вас вышло что весь текст вместе с вопросом оказался скрыт, и его потому не сразу заметили, хотя вопрос у Вас сложный для новичка в сетевых делах.