Nextcloud Client function on headless server (no desktop)

[cmonty14]

Feature description

Can you provide a full featured Nextcloud client on headless server (no desktop)?

Use case:
The (headless) server is a NAS and can then synch data to Nextcloud hosted externally (e.g. Hetzner).
Advantage:
Clients in local network have much faster response times connecting to NAS compared to Nexcloud via webdav.

THX

[joshtrichards]

How would that be different than running Nextcloud Server outright on your NAS?

I assume you've also explored using nextcloudcmd on your NAS as an option?

https://docs.nextcloud.com/desktop/3.10/advancedusage.html#nextcloud-command-line-client

[labor4]

use case:
sync TBs of data inter-server off-site in collab videoproduction. (basically DIY what BlackmagicDesign is currently rolling out)

note: As BMD is making a difference between masters and proxies, it begs the question how far one could even go with a general purpose server such as Nextcloud. Some things you just don't want to sync. But thats a different book entirely.

nextcloudcmd may or may not be suitable.
i couldn't get warm with it, because it is not aware of inotify things, it is limited to the indexing time range, and i don't get much of a response if i want to check and have a look at it. also i'm not sure if it's en par with the desktop client regarding conflicts.

personally i would wish for the desktop client+nextcloudcmd to have a unified framework such as Pydio's client or Expandrive's Linux client (client as a local server), because you can develop all functionality in one place while being able to run it headless anytime. You just hook up the gui to the client's running core, and disconnect from it if you want.

[Nebucatnetzer]

This is a similar issue to this one:
#4192

[ThaDaVos]

I just left a comment on #4192 which may be an interesting solution:
#4192 (comment)

[Rello]

Hello,

nextcloudcmd is not in focus for us anymore as virtual file systems are the future.
Nevertheless we will still support the current implementation and accept community contributions as PRs.

Thank you for your support.

[ThaDaVos]

If

Hello,

nextcloudcmd is not in focus for us anymore as virtual file systems are the future. Nevertheless we will still support the current implementation and accept community contributions as PRs.

Thank you for your support.

If Virtual File Systems are the future, can you tell me or explain, how one has to set this up on a headless server without a GUI?
Currently nextcloudcmd is the only option to support this scenario - using WebDAV straight up or something is no-option as it doesn't have any conflict handling like nextcloudcmd does.

So please, enlighten me, how does one do this?

---

I still agree with the others, splitting the syncing engine from the GUI would be the best, a bit like how OpenSnitch does it, a daemon/service which does all the work and the GUI just connects and sends commands to it - this way, one could setup a custom frontend if needed, or just have the daemon/service running doing all the syncing work - seperating both could also make it lighter to run, easier to test and offer more flexibility in the future if a custom GUI is needed for a platform.

[radioagent]

It is sad :(
My scenario:
i have home server which works on ubuntu server without GUI.
In same time this server has SMB server to share some folders for media devices like TV and music box.
I need synchronize sometimes my media library with nextcloud on ubuntu server.

In any case, thank you for great product.

[Rello]

Hello @ThaDaVos
you have a very isolated use case I would say.
And when looking at the total number of users, compared to this use case, it has to be a prioritisation on what we work on.
And nextcloudcmd is not one of that unfortunately. Might change in the future, or being picked up by community. But nothing is planned from our side

[bronger]

It is fair enough if you prioritise like this. I also appreciate that the half-broken state of nextcloudcmd over the last years finally becomes well-defined. I kindly ask you to communicate this status clearly to fresh users, as the program itself remains available.

However, I find the communication suboptimal:

• Recommending virtual file systems as an alternative lets me wonder whether you clearly understand our usecases.
• Apparently, you do not “still support the current implementation”.
• Calling nextcloudcmd an “isolated use case” is a difficult statement, given that it is impossible to determine the demand. FWIW, headless servers as part of a team workflow are extremely common.