owncloud — чудовий іструмент, але зі своїми болячками… чи особливостями, про які варто принаймні, гхм, знати. ось прилад: я знайшов розташування свого сховища в файловій системі на сервері; цю теку (точніше, її бітьків) docker монтує як volume, коли піднімає контейнер, і в цю теку складає теки та файли, що їх я завантажую через веб-інтерфейс. гаразд, то чи можу я зайти «заднім входом». себто не через owncloud, а локально на сервері, і додати собі нашвидкуруч кілька потрібних тек?
ніт!
бо owncloud, на відміну звичайної операційної системи, зберігає базу даних файлів та дозволів окремо від самих даних — в базі даних, яка взагалі крутиться в іншому контейнері! я про це не подумав, і спробував… і почалися сюрпризи: спершу створених «в обхід» тек не було видно онлайн. потім з’явилися, але я не мав прав доступу до них через веб-інтерфейс — які б права я не налаштовував звичними chown/chmod на сервері.
все це чудово, але допис про те, як повернути собі контроль над ситуацією. owncloud має інструмент для «ремонту» — утиліту occ, але працювати вона має в контейнері, звісно ж. як? не гасячи контейнер (себто, без docker-compose down чи чогось подібного), ліземо всередину і отримуємо доступ до командного рядка з bash:
docker-compose exec owncloud /bin/bash
отримуємо root, але перемикаємося на користувача www-data, який є адміністративним профілем для роботи з owncloud:
su www-data
і далі — запускаємо occ для, скажімо, підчищування кешу файлів:
php occ files:cleanup
або, в гірших випадках (як мій, з розсинхронізацією файлової структури для одного користувача зі станом бази даних), для перескановування теки з файлами одного користувача (tivasyk):
php occ files:scan --path tivasyk/files
детальніше — в документації до occ.
висновок: навіть якщо теоретично можливо редагувати файли в обхід веб-інтерфейсу owncloud, напряму в локальній теці, і потім поновлювати кеш за допомогою occ — це поганий і потенційно ненадійний спосіб. правильно і надійно — дати owncloud самому виконувати його роботу, як задумано.