After lots of reading and frustration. First of all, make sure the normal user has read and write acces to the USB drive. The correct 'non-root' fix for having write acces to the USB drive is:
Step 1: Stop transmission daemon
sudo service transmission-daemon stop
Step 2: Add pi to debian-transmission group
sudo usermod -a -G debian-transmission pi
You can boot from the SD card then just use an attached SSD, but you can not get around using the SD card for booting.
Once booted you can make the SD card read only and make sure all the software etc is running of the SSD
As others have mentioned, df -h will give you overview. Also useful:
du -csh (show total disk space used in current tree)
du -csh /path (show total space used in specified tree)
du -csh (show space used in subdirectories)
You can also install the durep package which will give you a more granular breakdown of disk usage.
This will not really happen on the Pi unless one puts loads of stuff on there.
SD cards come in five maximum speed classes:
Class 1: maximum speed of minimum 1 MB/s
Class 2: maximum speed of minimum 2 MB/s
Class 4: maximum speed of minimum 4 MB/s
Class 8: maximum speed of minimum 8 MB/s
Class 10: maximum speed of minimum 10 MB/s
Above 10 MB/s there are ...
The Pi 2 should be able to run that HDD directly. However, by default the power to USB is limited to 600 mA, which is not enough (I've had the same issue with an external drive).
To make 1.2 A available -- which is fine if your power supply is up to it -- add the following to /boot/config.txt:
And reboot. Your HDD should now light up ...
I'm using a SanDisk Extreme Class 10 with UHS-U3 on my RPi3, I have the microSD driver overclocked and I hit 33.80MB/s while reading/writing.
Speed don't decrease with capacity, just ensure to use a good brand like SanDisk (Samsung had a hight corrupt % chances), If you need some speed, try to overclock your microSD card driver.
More info here
None of the answers here worked for me, so I am writing a new one referencing https://pimylifeup.com/raspberry-pi-torrentbox/ which worked great for me and allowed me to run transmission as pi user to access my USB drive. This is not directly answering the OP but this question is very popular (first Google result) for this sort of problem so I put it here.
Linux kernel is caching disk operations. That means data is written not in real time, but when it is "time to do it".
There could be two reasons of behaviour you described:
1. Your SD card (or disk) is not fast enough to receive all the data you are producing.
2. Once in 30-40 seconds kernel is 'flushing' it's disk buffers, which unluckily freezes all disk ...
I think it's unlikely that a Pi would work well, if at all, with FreeNAS.
Note the recommendation on their download page:
The new recommended boot device size is 8GB. FreeNAS 11 requires 8GB of RAM to run properly.
The Raspberry Pi 3 has 1GB of RAM. So that requirement seems to not be met, and it's not looking great so far for FreeNAS.
obarthelemy of ...
I suspect your issue is that you are mounting the vfat filesystem so that it is only accessible to the root user.
The vfat filesystem (being a very simple filesystem dating from the ancient days of DOS) has no concept of users and groups, but all files in UNIX systems must have an owner and group. To work around this, the Linux vfat driver defaults to ...
https://www.raspberrypi.org/documentation/linux/filesystem/backup.md explains backup and restoration.
You don't indicate what OS you are using but it is simple on any 'NIX system.
I use the following on macOS
# script to backup Pi SD card
# 2018-11-29 optional name
# DSK='disk4' # manual set disk
# Find disk ...
Already answered here dd-on-entire-disk-but-do-not-want-empty-portion
Assuming you want to save /dev/sdXN to /tgtfs/image.raw and you are root:
mkdir /srcfs && mount /dev/sdXN /srcfs
Use zerofill or just:
dd if=/dev/zero of=/srcfs/tmpzero.txt
To fill unused blocks with zero (wait for it to fill the file system completely then
This seems to be a classical unix rights problem. Let's have a look on it. To avoid confusion I set user of /media/NAS to root and then check where is the problem:
pi@raspberry ~$ sudo chown root /media/NAS
pi@raspberry ~$ mkdir /media/NAS/folder-pi # works
pi@raspberry ~$ su -l pi2 # login as pi2
pi2@raspberry ~$ mkdir /media/NAS/...
Another option could be to use an alternative to the Raspberry Pi with an SATA-interface, like the Cubieboard (see this list on Wikipedia).
On the other hand, SD cards are not as unreliable as you might think.
There are many ways you could set this up. You could use a whole host of software to mount the RPi's storage as an ftp or sftp drive, you could use OwnCloud, btsync, or a zillion other things that you could find by googling.
If you install netatalk on the Pi you can use it from OS X.
You can connect using open afp://raspberrypi.local on the Mac. It is also possible to connect from the sidebar in Finder although I find this annoying.
This lets you access the shared items in Finder or any other file utility.
There is some configuration on the Pi (which you can find in the man ...
Yes it will work. The Pi does not support the protocols (or have the hardware) required to implement the higher speeds such as UHS, but will operate.
Any Class 4, 6 or 10 card will work - the only difference between these is write speed (and this in burst mode). The read speed, which is arguably more significant for the Pi, depends on the manufacturer.
You can put your filesystem on an external drive, there are instructions to use an external drive to boot your Pi. See https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
Alternatively you can continue to boot from SD Card, and use external mounted storage. See https://www.raspberrypi.org/documentation/configuration/external-...
cmdline.txt contains root=/dev/mmcblk0p2 rootfstype=ext4 indicating the root partition.
I assume that if you used a SSD with a suitable partition you could use root=/dev/sda1 (or whatever). I have not tried this (and don't share the paranoia many seem to have about using SDCARDS).
It is not clear whether Raspbian contains the SSD trim support needed to ...
Partitioning the flash drive is a decent solution and one I use in my own setup. The downside to this method is that the drive will no longer work on a Windows environment, since Windows will only recognize the first partition on removable media.
Alternatively, you can mount the drive under /mnt/usb, and then create two folders: /mnt/usb/database, and /mnt/...
From the Ubuntu Mate Raspberry Pi page
to re-size the file system:
sudo fdisk /dev/mmcblk0
then delete the second partition and recreate it by selecting the following menu options:
then reboot the system.
You can check if your SDCard has been tested here http://elinux.org/RPi_SD_cards and see the results. Probably it will work without problems. Also you can add your test if there isn't available. You can help other people.
You can build such a thing with a Pi. However, the problem would be how the head unit accesses the MP3 files, and the fact that you are changing it out from under it. Most programs (like the one the head unit is running) won't handle that correctly and give a variety of errors, including crashing.
For the hardware, you probably want something like this, ...
The first line of df isn't saying the root directory is using all that space, that's the root mount point, containing every directory which isn't covered by one of the other mount points.
I suspect the transmission directory isn't on the USB stick as you intend but actually on the SD card.
You can use the du command to examine where space is being used. (...
The behavior you describe can apparently be achieved through installation and configuration of the hdparm utility (ref).
You might check the Arch Linux repo for this package, or you might try posting this same question on the Arch Linux New User forum.