simple webdav server that’s compatible with the Nextcloud sync clients

Now THAT is interesting - when I was last experimenting with Nextcloud I learned that the files part is just a webdav server. Unfortunately I also learned that they have a bit of a handshake before the webdav so the client wouldn’t work with my apache2 webdav server. Thanks!

That seems to be the case. Really sucks that the documentation at nextcloud.com directs people to the AIO. I guess they hope that if you have a bad time trying to install your own server you might buy their cloud service.

Yeah, I can see how someone that has “grown up with it” could be happy. But as and experienced sysadmin coming at it for the first time - the documentation is a bit lacking.

Because an android client is one of my requirements. I can get files from SMB on Android using any number of file managers, but I can’t map a SMB share to a filesystem so files are available for an app to use.

Yes! There used to be a little utility that could map a SMB share in Android, but that got killed years ago.

So, use something else

That’s why I’m here - looking for suggestions

like Seafile.

I’ll have another look - you’re not the only person to suggest it. My recollection is that it seemed to be old and not really maintained.

I’ve never used the AIO image. I’ve heard it’s weird.

It does seem to be. So, I find it weird that the “core” documentation leads a new user to installing AIO.

You could also try OpenCloud, which is a Go rewrite of ownCloud.

Sounds interesting - thanks.

You need to understand the difference between a docker run command, and detaching to run a container in the background. Just running it with ‘run’ keeps it in the foreground.

Yes, I understand this. I was just highlighting that it’s not a great experience for a new user to follow the instructions to setup a server and be left with it running in the foreground.

For the passphrase issue: https://github.com/nextcloud/all-in-one/discussions/1786

Thanks! This should get me past my current hurdle so I can do some more testing. Again - not a great experience to have to come to a forum to get help to find a passphrase. I’m pretty sure I didn’t miss any steps?

Lastly, if you’re not familiar with containers, and this is a single purpose machine, you’d be better off just running the bare project on the host. If there’s no need for containerization, just skip it.

I’m familiar with containers, but think they’re overused. Stupid little things that are a single Python script (for example) shipping as a Docker image! But, I thought Nextcloud was complex enough to be worthy of a container? This is not a single purpose machine, but I’m an old, retired, sysadmin - I have no problem running a few different servers on the same host.

Are you referring to the “Archive” Community Project installation method?

Use docker or podman compose https://hub.docker.com/_/nextcloud/

I could do that - I guess I was just pointing out that someone coming to Nextcloud and following the install instructions does not have a great experience.

Nextcloud does not need a domain. Ip is fine.

So, their documentation is wrong?

https://github.com/nextcloud/all-in-one?tab=readme-ov-file#can-i-use-an-ip-address-for-nextcloud-instead-of-a-domain

Again - not a great experience for a first time user.

I get what you’re saying, but beware of the non-wifi devices that only operate through a proprietary gateway to a cloud-only service.

Almost a chuckle

Protecting children would mean knowing which users are children, which would mean knowing the actual legal identity of every user of the platform. It’s never going to happen.

I assume “data” includes your container configuration files in this strategy?

It should be obvious from the context here, but you don’t just need geographic separation, you need “everything” separation. If you have all your data in the cloud, and you want disaster recovery capability, then you need at least two independent cloud providers.

I used Kodi and now use Jellyfin as client/server - my media is on a local server. The difference (the way I use it) is that with Kodi the server was just a file server and the client (Kodi) was doing all the work. The Jellyfin server is a media server and the clients are very lightweight. I was pushed to move to Jellyfin when I got a new Sony TV - the built-in Android TV experience was very usable but I couldn’t install Kodi - it ran out of space trying to build the media database. I’m sure there are ways I could have made it work, but I’d heard about Jellyfin and figured I’d try it. I liked it and never went back.

All that makes sense - except that I’m taking about 1or 2 physical servers at home and my only real motivation for looking into containers at all is that some software I’ve wanted to install recently has shipped as docker compose scripts. If I’m going to ignore their packaging anyway, and massage them into some other container management system, I would be happier just running them of bare metal like I’ve done with everything else forever.

I think Kodi was amazing when it was XBMC and the only real option. It seems to be falling behind now though :-( I moved to Jellyfin a couple of years ago.

Currently no virtualisation at all - just my OS on bare metal with some apps installed. Remember, this is a single machine sitting in my basement running Samba and a couple of other things - there’s not much to orchestrate :-)

Wow - I thought docker was overkill for a home server and you’ve gone kubernetes! I guess if you use it for work and that’s what you’re comfortable with?

Because it seems overkill for a home server. Up until recently all I ran was Samba and a torrent daemon. Why would I install another layer of overhead to manage two applications on one server?