Good Morning everybody,
I do have a issue, with a integrated external storage of my Nextcloud environment. The storage was integrated at the admin page by using ftp.
Thus it isn´t related to a user but to the system.
The configuration of this storage is set to encrypted and without rescan (in the beginning it was activated to check at every access) the external storage.
All data (folders as well as files) on that storage was upload by nextcloud (no direct uploads to the ftp storage).
Suddenly the contents of that storage disappears (not all at the same time but in differnet steps until the folder became empty) on nextcloud web and the clients removed the files from lokal sync folders.
To reintegrate the “lost” data I started a “files:scan --all” but except a couple of short appearings of some folders, the main folder remains as an empty one.
I found out that suspiciously I can browse into all folders by typing in the directory within the url. This is also possible for the files.
After I done this for a particular file or folder, it appears in the filebrowser of nextcloud web as well as in the clients.
While I was doing that I monitored the database and the servers` data folder but wasn´t able to encounter differences.
Under the bottom I do have the question what I´m able to do for a complete reintegration including all folders and files without losing the encryption keys to get access to my data.
I have to add that the foldes / files I manually opened by their URL appears at least for a couple of hours, maybe until some process. Afterwards this folders / files disappears again.
Can you have a look into your logfiles? The files disappearing from Nextcloud are still available on your FTP storage?
Thanks for your quick reply.
The files are still available on my FTP.
Unfortunately I´m not able to open/edit them due to the encryption. Otherwise I would copy them from there directly to nextcloud to remove the FTP integration later on.
But first I have to get my files in readable manner back.
At the nextcloud/data/nextcloud.log I´m able to encounter a couple of errors due to aborted transfers.
Honestly I´m not sure what I´m looking for exactly.
Database error, connection errors (to ftp), …
Can you give some information about the version and environment you are using?
the log is massive, that is the reason why I wasn´t confused by looking for messages.
I have grepped for strings like ftp and error and found a couple of entries.
This entries names fseek() - stream does not seeking and stat() ssl handshake timed out / stat failed for ftps<- the integration is with ftp and not with sftp
VM on CentOS HOST with SolusVM
OS - Ubuntu 16.04.1 LTS
CPU - 14 cores (have to look for the particular cpu)
memory - 23,54 GB working memory
swp - 16GB
space / disc - 3,1tb ssd RAID 5
Nextcloud: 10.0.2 (184.108.40.206)
Is there any possibility to copy the data onto the server or another ftp storage and integrate it including the encryption keys?
I would like to exclude the current FTP drive as the source of this issue.
It seems the best that you open a new bug report on github.com/nextcloud/server/issues and provide all details asked in the issue template.
Many thanks for your recommendation.
I will do so.
I am have the same issue here. I’ve tried to re-install nextcloud, but the external storage does not appear, and there are no files. The connection only appears in the “External Storage”, but clicking on it takes be back to the some file location. I’m using Ubuntu 16.04 with an SFTP connection to a file server that is a mac.
workaround for me:
make an local mount on the server where nextcloud runs (with curlftp for example) and add a external storage with type local in nextcloud. faster, and saver way!
fstab-entry is like this:
curlftpfs#USER:PW@192.168.5.2 /mnt/ftp/posseik fuse noauto,x-systemd.automount,user,uid=1000,allow_other,disable_eprt, 0 0
I also got an question - how can i prevent, that the external clients download external storage by default?
I tflidd ! Where is the solution on this links ? Thanks.
I my case, the porblem was that the user name in Webdav url is case sentive, because this username indicate the directory. If the casing is bad the directory does not exist.
https://nextcloud.fr/remote.php/dav/files/bill is not the same than