this post was submitted on 20 Jun 2023
0 points (50.0% liked)

Self Hosted - Self-hosting your services.

11086 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules

Important

Beginning of January 1st 2024 this rule WILL be enforced. Posts that are not tagged will be warned and if not fixed within 24h then removed!

Cross-posting

If you see a rule-breaker please DM the mods!

founded 3 years ago
MODERATORS
 

I have a Raspberry Pi with a 2TB SSD on which I store all of my media. That media sits in a directory that is capable of being mounted on other computers via NFS.

I have that directory mounted on another computer via NFS in /mnt. I am able to create directories, create files, move files there, and they show up instantaneously on the Raspberry Pi (I do this without sudo because I gave my user write permissions via chown).

However, when I attempt to download a torrent via Transmission and have it automatically save to the NFS-mounted share, it does so for a few seconds, then gives me one of the two following errors:

Error:  Permission denied (/mnt/....)

or

Error: Read-only filesystem (/mnt/....)

My Transmission Daemon user is set up to be my normal user.

Anybody have any ideas? I followed these three tutorials to set it all up:

Thank you in advance for any help you can provide.

top 9 comments
sorted by: hot top controversial new old
[–] [email protected] 2 points 1 year ago (2 children)

Who owns the mount point under /mnt? If it's owned by root you could try changing ownership of it to your user

[–] [email protected] 1 points 1 year ago

I tried changing it just now to me and got this error:

[username]@[hostname]:~$ sudo chown -R [username]:[username] /mnt
chown: changing ownership of '/mnt': Read-only file system

Is there a way to make it writeable? Is that something I even want to do?

[–] [email protected] 1 points 1 year ago

Okay I managed to solve it with two things:

  • in settings.json, changed umask from 18 to 2.
  • in settings.json, changed incomplete dir from true to false (it didn't seem to like ANYWHERE that i put this so I just said screw it, let's not have one, it's not that big of a deal)
[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

20mbit/s per second is not so much, but it should work. In general you have to differentiate between three things with Lemmy:

  1. Users on your own instance directly utilizing the client api (medium bandwidth heavy, medium CPU)
  2. Users from other instances indirectly accessing communities (low bandwidth, but potentially high CPU)
  3. Either of the above directly loading images from your instance (potentially very bandwidth heavy)

For 1: you can limit the number of people you allow to sign up on your instance (highly recommended)

For 2: this is depends on the number of subscribers and the number or external servers but overall is relatively efficient as the remote servers take most of the load, but your server will still have a high database load if remote people comment and post a lot.

For 3: Until Lemmy implements a fully image proxy, this will likely be your main problem with only 20mbit/s upload. But you can severely limit the size of images being uploaded and convert them to smaller sized webp images automatically. But if a lot of people try to download the same image from your instance, it's going to be a problem.

[–] [email protected] 1 points 1 year ago (1 children)

I think you replied to the wrong thread

[–] [email protected] 2 points 1 year ago

indeed, thanks!

[–] [email protected] 1 points 1 year ago (1 children)

What is the output of

mount | grep mnt
[–] [email protected] 1 points 1 year ago

I actually managed to solve it as shown here

[–] [email protected] 1 points 1 year ago

Impressive, how did you set that up?

Good luck too btw 👍

load more comments
view more: next ›