Why no real db? Those other 2 features make sense, but if the only option you can use sacrifices the 3rd option then it seems like a win. Postgres is awesome and easy to backup, just a single command can backup the whole thing to a file making it easy to restore.
I think oCIS spoiled me with regards to the database issue xD. You bring up a good point - I’ll try reinstalling Nextcloud with Postgres, removing unneeded bloat, and use it until oCIS has a “native” backend
Another thought: I use grocy (or at least try to use it) to have an overview of my stock and know when an open item in the fridge neeeds to be used before spoiling. But I just use a shared note on nextcloud for shopping, which is good enough for two people. But of course there is no meal planning or recipe management
For testing I just spun up a VM with Docker, I tried the same compose file as you. I found I had to use the volume instead of a bind mount for /app/storage.
Oh wow, thanks for trying this. It is working indeed.
I am an absolute begginer so let me ask. Where is shotshare_data on my machine ? Is it in docker volumes ( like /var/lib/docker/volumes/) ? Is there a way I can store data in /srv/dev-disk-by-uuid-7fe66601-5ca0-4c09-bc13-a015025fe53a/Files/Shotshare/ ?
It will be stored in /var/lib/docker/volumes, you can find the exact location by inspecting the volume. Use docker volume ls to list the volumes, and do docker volume inspect <volume_name> replacing <volume_name> with the one from the list. Look for “Mountpoint”, that is the exact location. You could try copying that to bind mount location, though I can’t be sure if it will continue to work.
You should be able to create the directories manually. I cheated by simply cloning the repo and copying them to the bind mount location like so. You can use the bind mount method like you wanted.
Ran into a similar conundrum. We use mealie for recipe management and occasionally meal planning, but the shopping list is clunky. We resorted to just making a list on a card in Planks. Not purpose-built, but it has worked rather well for us.
I like the recipe management, but I dislike the grocery list for the same reason I don’t like Grocy. It is just too complex and hard to use in the store.
I’ve been extremely fond of “Our Groceries” for many years. It strikes a sweet spot between features and simplicity of use, and the devs are very responsive and have added several features after my suggestions. Really the only downside right now is that it can’t use the front facing camera on my wall mounted android tablet for scanning barcodes.
I thought I’d give this a shot, but the metrics/data collection flag was turned on by default and when I added a command to my docker-compose to turn them off, it was ignored. Then, I created an account and looked for a way to turn them off in the settings and there was none. You expect people interested in self-hosting OSS to be cool with sending data out of their network every time the server is started, a memo is created, a comment is created, a webhook is dispatched, a resource or a user is created?! Also, the metrics are collected by a 3rd party with their own ToS that could change at any time?
Holy hell, hard pass. I’d rather use a piece of paper.
Saved me the effort, thanks. Although, couldn’t you just block the container from talking outside your network? I can’t see why I’d need a memo app (server) to have access to the internet.
That’s not good enough in my opinion, it should be opt in, not opt out. They’re marketing it on their site as being more secure because you can self-host. It all just seems really skeevy.
It would appear that blocking app.posthog.com on the host/network resolves this. But I got the parameter to work, too, as per www.usememos.com/docs/advanced-settings/metrics use ‘–metric=false’ and bam, no DNS queries!
Yeah, I’d assumed it would respect the —metric=false flag when building with docker run, but docker-compose is ostensibly supported and easier to work with. I was able to successfully change other configuration options (such as setting the db to use MySQL instead of the default SQLite) using the docker-compose ‘command’ block, but the metric flag specifically was ignored. It’s entirely possible that this is a bug and not an intentional attempt to hoover up user data. Either way, data collection should be opt-in by default (by law, imo).
selfhosted
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.