hafis

Да, в меню там выбраны были "Все ссылки". Но тех ссылок, что пользователь создал механизмом Synology Drive на своем компьютере - там нет. В этом - и вопрос. Любой пользователь Synology Drive может повторить описываемые действия: создать ссылку общего доступа используя клиент Drive на компьютере (ссылка создается через контекстное меню, когда курсор на файле). Потом зайти в DSM и убедиться, что в диспетчере ссылок её нет. Но ссылка будет рабочей. "Видишь в диспетчере ссылку? Нет? А она - есть!" (с) ДМБ

Приветствую! Вопрос по интерфейсу DSM, если в нем вообще есть такая возможность посмотреть. Описание ситуации: Пользователь кладет файл на свой Synology Drive на своем компьютере. Пользователь на своем компьютере создает ссылку публичного доступа к этому файлу. Эта ссылка публичного доступа рабочая, действует (проверил) Я как администратор synology хочу проверить как контролировать создаваемые пользователями ссылки общего доступа, сроки их действия и т.п. параметры. Захожу в интерфейс DSM (6.2.4), захожу в FileStation - инструменты - диспетчер ссыл

Приветствую! Долгие годы использовал DS Cloud на Андроид для синхронизации файлов, создаваемых в каталогах телефона и планшета, с NAS. В частности, синхронизировались каталоги DCIM, callRecorder, Music и некоторые другие. Было очень удобно: телефон создал файл, я его могу просмотреть/прослушать на ноутбуке, там же на ноутбуке удалить его, к примеру, и он впоследствии удаляется с телефона. Прекрасно. И этот механизм работал даже когда телефон и ноут были временами оффлайн. Наступили новые времена. DS Cloud теперь несовместим с сервером Synology Drive на NAS И этот ме

Спасибо всем ответившим. Попробую.

Здравствуйте, коллеги! Имеется: Дистанционно расположенный компьютер под управлением Win7 (комп за несколько тыс. км, доступа к нему нет) С него делается периодически резервная копия средствами Active Backup for Business, тип источника: "системный том" Актив бэкап работает на DS412+, (Virtual Machine Manager для легкой беспроблемной конвертации с архива в виртуальную машину на нем запущен быть не может) Задача: поднять всё, "как есть" с данного актуального архива в виртуальной машине на VDS или в виртуальной машине на выделенном сервере, с hyper-v. То есть, конвертировать а

Если Вы - владелец домена, то в DNS-записях для этого домена просто прописываете IP вашего NAS, вместо сервера у провайдера. Это абсолютно штатная процедура при "переезде" серверов с одного размещения на другое. Такой опыт есть. Но, в моем случае был выделенный белый IP. В роутере прописывается проброс портов, необходимых для работы почтовых служб (25, 443, и т.п.). В DNS-записях домена этот IP является значением для MX-записей. Но, впоследствии эта практика была прекращена. А почта перемещена на нормальный сервис VDS, который по сегодняшним временам стоит недорого. Потому

Ну, до недавнего времени коробчонка с душой вела себя прилично. несмотря на то, что я регулярно обновлялся. Когда NAS доступен, то в веб-морде загрузка памяти не больше половины имеющегося. И свободного места на массиве еще пара терабайт. Никаких проблем с коробкой до недавнего времени не было. Да и не так много пакетов в него загружено. В моем случае, фактически, работает только Active backup и старенький Cloudstation server. И да, отлучение NASa от интернета путем физического выдергивания IP-шнурка - бешеную пляску дисков не прекращает. Получается, это не обмен данными с внешни

Итак, повторилась ситуация, описанная в стартовом посте про мой NAS. Та же история: бесконечно (cутки уже) стрекочет дисками, SMB отвалилась. В панель управления DSM иногда пускает, но диспетчер задач вызвать уже не удается. В общем, симптомы заболевания "бешенством самозанятости" - все те же, как описаны в старте топика. Попытался зайти по ssh. А вот хрен! Putty дает ввести логин, но после ввода пароля вывешивает транспарант: "Remote side unexpectedly closed network connection" bitvise тоже многословно сообщает, что, ssh сессия прервана с ошибкой. connection, дружище, lo

kucher, конечно, тут никаких противопоставлений, понятно, что мы сейчас просто гипотезами обмениваемся, в надежде понять возможные процессы, получившиеся настолько возбужденными.

Drive Server я на этот NAS не ставил. Cloudstation server - установлен и используется. Но, ранее за ним я таких отвязных финтифлясов - не наблюдал. Обычно он шебуршит что-то там, тихой сапой в фоновом режиме, и не отсвечивает. Из пакетов, активно работающих с файлами, установлено: -- Cloud Station server -- Active Backup for Business (последнее успешное задание выполнено три дня назад, а далее пакет тупо ничего не смог сделать) -- Universal Search (но, индексируемых папок там не настроено) -- Hyper Backup (но, все дестинейшины для него были физически отключены) Подозр

DS412+ 3 диска RAID5, BTFS DSM 6.2.3 Очень активно и безпрерывно стрекочет дисками. Как минимум сутки, а может больше. При этом пользовательские сервисы: файловый сервер, сервер cloudstation, web-сервер - недоступны. Доступа по SMB нет. Сервисы (cloudstation, etc) фактически не функционируют. Даже простенький сайтик маленький быстрый, размещенный на NAS - и тот не отзывается. С большим трудом, не с первого раза, зашел через браузер в панель управления. При этом страничка в браузере грузится прям несколько минут. Видно, что аппарат занят чем-то своим, очень интимным, но то

В обозримой локальной окрестности нет линукса. Только виндус. Доступа с внешнего мира тоже нет (серый IP). А MC под виндус не умеет Shell Чем возможно просмотреть ситуацию более подробно из под винды в локалке?

В пополнение к предыдущему: Это домашний NAS, использовался как файлопомойка и для бэкапов настольного Мака. (в папку backup***) Никаких там докеров, хренокеров, LUN for iSCSI и проч - не делалось. Да и не умеет 413j шибких сложностей. До этого "раздел 1" жил на 212j, Там как раз и заполнился полностью. Что послужило причиной миграции на 413j и последующим разборкам "а что там хранится-то?" Вот этот, неизвестный никому, и не принадлежащий никаким общим папкам терабайт данных появился еще при жизни двух дисков в 212j. Такие, вот, странные дела. "Что это было, Хол

Имеем DS 413J Изначально был на нем один дисковый массив, (2 диска по 3 ТБ). Который постепенно заполнился. Назовем его "раздел 1" Решили расширить систему хранения, вытащив из загашника еще пару дисков по 2 ТБ. Поскольку Синололжи умеет расширяться только на дисках не меньшего размера, решили это сделать таким образом: 1. Создаем второй пул хранения и второй раздел (назовем его "раздел 2"). 2. Перенесем на "раздел 2" все общие папки. 3. Грохнем "раздел 1", диски по 3 ТБ освободятся 4. Проведем ребилдинг второго пула хранения, добавляя к нему освободившиеся диски.

демон с рутовыми правами, самостоятельно живущий внутри Синололжи абсолютно вне контроля пользователя Синолоджи - это конечно не дыра, а только предпосылка к ней. Зная, что такие предпосылки уже имеются, пользователь может выстроить определенную стратегию в отношении своей информации. Ну или, беззаботно отмахнуться, однако уж с полным осознанием ситуации. В этом - суть и смысл и того и этого обсуждения. А отнюдь не в том, чтобы всем тут думать: "как противозаконно использовать этого демона - еще не придумали, поэтому потенциальных опасностей тут нет никаких вообще". Мне каж