User Data Location on NFS Drive

Hi all,

I have an RPi2 that I’m mainly using as cloud file storage with OwnCloud. It died on me yesterday. I did some troubleshooting, looked like the SD card got full for some reason and that crashed the entire installation… Anyway, I noticed there’s a new kernel out and decided to do a fresh installation instead of trying to mess with an update.

So, I downloaded the image. Set up most of the stuff but I just can’t figure out one thing. All my files are hosted on a NAS. Nothing is connected to Pi other than a LAN cable.

The problem I’m facing is, I can’t change the “User Data Location” to point at the network drive. When I try, I get this:

I tried adding the network drive as SMB and NFS. Tried chown on the mount point.

I know the share itself is working because I can navigate to mnt/NFS and do an ls and see all the folders. I can use mkdir there too.

I did some reading and it looks like we’re no longer allowed to create Symlinks to NTFS drives from Pi for security reasons? I can’t believe I’m the only one who’s trying to use an SMB share as storage for Cloud or Torrent software. What am i missing here?

PS: Here’s the current state of my /etc/fstab if that matters:
Screenshot 2022-01-22 222641.jpg
Thanks for the help.

for Samba this is as expected as Samba did not support native symlink and UNIX permission.

For NFS I’m not 100% sure. I see some changes done on version 7.8.
Network shares are not supported in general but might become available on a future release. Theoretically I agree with you, NFS should be working as long as it support native symlink and UNIX permission.


I’ve been using SMB shares for my Owncloud for about 5 years. Never had a problem with them before. Which is what made me think maybe I was doing something wrong this time.

Tried to manually point Owncloud to network share but it looks they’ve changed how they store configurations since the last time I’ve worked with it. I tried to modify the keys in MariaDB to point at NFS share but that didn’t work and I messed up the installation.

I’m giving NextCloud a shot now in the hopes that it’ll allow me to change its storage path easier. But I’d really love to have a way to use a network share as I did before.

You are doing way to complicate. Stop all services. Simply move (or use rsync) whole dietpi user data directory to your share. Create a symlink from /mnt/dietpi_userdata/ to new location. And start all services again.

Nothing else would be done by DietPi drive manager.

That’s what i’ve been trying to do. But having trouble with file permissions. Here’s my fstab: /mnt/dietpi_userdata/nextcloud_data/ cifs cred=/var/lib/dietpi/dietpi-drive_manager/mnt-samba.cred,iocharset=utf8,uid=www-data,gid=www-data,file_mode=0770,dir_mode=0770,vers=3.1.1,nofail,noauto,x-systemd.automount

NextCloud is giving this error:

Your data directory is invalid Ensure there is a file called “.ocdata” in the root of the data directory. Your data directory is not writable Permissions can usually be fixed by giving the webserver write access to the root directory. See >> .

This is a SAMBA share and not working as I explained above. Samba did not support Unix permissions. You have as well the database located inside the DietPi user data directory. And the database requires different permissions than user www-data. This is just one point. There might be other files and folders as well. Don’t use samba to host your user data directory. Use NFS with full support for Unix permissions and symlinks

Since the Samba mount is at /mnt/dietpi_userdata/nextcloud_data and not /mnt/dietpi_userdata itself, it does not include the database and could be fine. But, AFAIK, ownCloud and Nextcloud require UNIX permission support for the data directory as well, hence do not support Samba. For performance reasons it is a very bad idea anyway: Both are designed to host the files locally at the cloud server system. You can attach a Samba share as external storage within their web interface and the external storage app. This does not include the locally stored data but it makes available the data from the share to the clouds interfaces and clients.

What are actually the resulting modes of your Samba mount currently?

ls -al /mnt/dietpi_userdata/nextcloud_data

ah right. I totally overlooked that it was nextcloud_data and not /mnt/dietpi_userdata. My fault.

I’ve found a workaround that mostly solved the issue for me.

After reflashing the SD Card again, I noticed in the Boot Drive there’s a DietPi configuration. In it, there’s the section where you can set which path NextCloud or OwnCloud will use to store their data. I set both to /mnt/NFS/cloud.

After doing the first time setup, I mounted my NAS as an NFS share. Did the chown www-data thing, then, I installed Owncloud as usual and voila. It’s using my NAS as its storage. Considering the DB and Logs are still stored on the SD card, this will probably cause problems for me down the line but that’s the future me’s problem…

I get using SMB share might not be the most optimal solution. But I use OwnCloud mostly to manage my library. e-Books are usually 400-500kb individually and in the entire archive is just a couple of GBs. I don’t really care if the connection isn’t blazing fast, all I care about is that it’s headless. i.e The Pi won’t crash in a year because logs filled its storage or something like that.

I’d suggest allowing SMB shares to be used for userdata. You could warn users that what they are doing is not the optimal or safe way but just let people do what they want. I got the feeling that a significant percentage of people who are using DietPi aren’t well versed in Linux and making things as easy as possible is likely a good idea.

This thread can be marked solved. Thank you for the help and keep up the good work!

Great that this works. That the database is not on the NFS mount is definitely what you want! The many short queries Nextcloud does on MariaDB would suffer from a massive performance break down what this all would go through non-native network connections. Also database corruption on network issues could happen easily. If you would want to have the database on a different server, it should run on a different server and can be accessed via its native network functionality, where it is able to handle network connection losses, issues and such gracefully.

That’s a good point actually. Pretty sure my cheap Asus NAS wouldn’t allow me to install MariaDB on it. Even if it did, setting it all up is just too much work for what I want to achieve :slight_smile:

Again, thanks for the help!