• 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: September 25th, 2023

help-circle

  • FAT32 doesn’t support unix file permission, so when you mount the disk linux has to assign a default ownership which usually is to root. And this is the issue you are facing.

    You confused the disk permission with the filesystem permission. The udev rule you wrote gives you permission to write the disk (in other words, you can format it or rewrite the whole content) but doesn’t give you permission on the files stored inside because they are on a higher abstraction level.

    If you use this computer in interactive mode (in other words if you usually sit in front of it and plug the disk on demand) my suggestion is to remove that line in /etc/fstab and let the ubuntu desktop environment mounting the external hard drive for the current logged in user.

    If you use this computer as a server with the USB disk always connected (likely since you mention Jellyfin) you need to modify the fstab line to specify which user should get permission on the files written on the disk.

    You can see the full list of options at https://www.kernel.org/doc/Documentation/filesystems/vfat.txt

    You either want uid=Mongostein (assuming that’s your username on your computer too) to assign to yourself the ownership of all the files, or umask=000 to give everyone all the permissions to the files and directories while ownership will remain to root. You should prefer the second option if jellifin runs as a different user, while the first one is better if there are other users on your computer which shouldn’t access your external disk.

    To summarize, the line in /etc/fstab should be one of these two.

    LABEL=drivename /mnt/drivename/ auto rw,user,exec,nofail,x-gvfs-show,dev,auto,umask=000 0 0
    
    LABEL=drivename /mnt/drivename/ auto rw,user,exec,nofail,x-gvfs-show,dev,auto,uid=Mongostein 0 0
    

  • There is no need to add a udev rule to make the device writeble by your user. If you have a full Ubuntu setup the external drive should appear in Nautilus as soon as you attach it and it can be mounted and umounted from UI.

    if it doesn’t work you can add a line te /etc/fstab like

    /dev/sdb1 /mnt/mydisk noauto,user,uid=yourname 0 0

    duble check the man page for the right sintax (I’m going by memory), but what you are saying here is that any user can mount this device which shouldn’t be mount automatically on boot, and files there are owned by the user “yourname” The issue with this approach is that the device name changes depending on what you have connected, Udev should also add some symlink which contains the device ID so it is more stable.


  • I got a terramaster nas and I’m super happy https://www.terra-master.com/global/f4-5067.html

    The main reason to choose it is that it is just a PC in the form factor of a NAS. You can just boot it from a pendrive and install your favourite operating system. I had a Qnap before, and while it was great to start, self hosting wasn’t the best experience on their OS.

    this is a small form factor, it should be low power consumption (I’ve never measured to confirm it) and supports both nvme and sata drives. Currently I’ve an nvme for the OS and two sata for storage. CPU is powerful enough to run home assistant, vpn, pihole, commafeed, and a bunch of other Docker images. I just plan to increase the ram soonish because the stock feels a little constrained.


  • I did some experiments in the past. The nicer option I could find was enabling webdav API on the hosting side (it was an option on cPanel if I recall correctly, but there are likely other ways to do it). These allow using the webserver as a remote read/write filesystem. After you can use rclone to transfer files, the nice part is that rclone supports client side encryption so you don’t have to worry too much about other people accessing files.


  • After looking around a little I couldn’t find any zigbee thermostat which met all my needs (mostly, I couldn’t find any which switches high voltage and has a wireless sensor that can stay in a different room).

    so I went for the fully custom setup: a normal zigbee switch connected to home assistant and controlled by their software implementation of a thermostat. The temperature sensor is a template sensor which takes the temperature of the living room during daytime and the bedroom during nighttime. I have automation to change the target temperature during day, night and when the house is empty.

    pro: fully customizable by software, dead cheap con: the heating needs your server to work correctly

    Some failure modes I found and their workaround:

    • The temperature sensor goes offline. I have automation to turn off the heating and send a notification
    • the server goes offline: I left the old dumb thermostat wired in parallel, it can guarantee the home will not go too cold.

    the only failure mode I’m still concerned is if the server goes offline while heating is on. In this case there is nothing to turn it off again. I was looking for zigbee switches with a timer to switch off automatically but I couldn’t find any. So if I’m out of home for more than one day I disable it and revert to the dumb thermostat.

    my suggestion here is: whatever solution you choose, be sure to have a plan b in case whatever smartness you have stops working (cloud service or local home assistant offline)


  • Could it be that the domain name has both IPv4 and IPv6 and depending on the network you try to reach one or another? Wireguard can work on both protocols, but from my experience it doesn’t try both to see which one works (like browsers do). So if at the first try the dns resolves the “wrong” IP version, wireguard cannot connect and doesn’t fallback trying the alternative.




  • A lot of technical aspects here, but IMHO the biggest drawback is liability. Do you offer free storage connected to internet to a group of “random tech nerds”. Do you trust all of them to use it properly? Are you really sure that none of them will store and distribute illegal stuff with it? Do you know them in person so you can forward the police to them in case they came knocking at your door?


  • Yes, you can do it on your server with a simple iptable rule.

    I’m a little rusted, but something like this should work.

    iptables -t nat -A PREROUTING -d [your IP] -p tcp --dport 11500 -j DNAT --to-destination [your IP:443]

    You can find more information searching for “iptables dnat”. What you are saying here is: in the prerouting table (ie: before we decide what to do with this packet) tcp connections to my IP at the port 11500 must be forwarded to my IP at port 443.


  • For automatically unlock encrypted drives I followed the approach described in https://michael.stapelberg.ch/posts/2023-10-25-my-all-flash-zfs-network-storage-build/#auto-crypto-unlock

    The password is split half in the server itself and half in a file on the web. During boot the server retrieves the second half via http, concatenates the two halves and use the result to unlock the drive. In this way I can always remove the online key and block the automatic decryption.

    Another approach that I’ve considered was to store the decryption keys on a USB drive connected with a long extension cable. The idea is that if someone will steal your server likely won’t bother to get the cables too.

    TPM is a different beast I didn’t study yet, but my understand is that it protects you in case someone steals your drives or tries to read them from another computer. But as long as they are on your server it will always decrypt them automatically. Therefore you delegate the safety of your data to all the software that starts on boot: your photos may still be fully encrypted at rest so a thief cannot get them out from the disk directly, but if you have an open smb share they can just boot your stolen server and get them out from there





  • I remember this blog post (I cannot find right now) where the person split the decryption password in two: half stored on the server itself and half on a different http server. And there was an init script which downloaded the second half to decrypt the drive. There is a small window of time between when you realize that the server is stolen and when you take off the other half of the password where an attacker could decrypt your data. But if you want to protect from random thieves this should be safe enough as long as the two servers are in different locations and not likely to be stolen toghether.


  • TPM solves a sigthly different threat model: if you dispose the hd or if someone takes it out from your computer it is fully encrypted and safe. But if someone steals your whole server it can start and decrypt the drive. So you have to trust you have good passwords and protection for each service you run. depending on what you want to protect for this is either great solution or sub optimal