Hello all, I apologise for asking a likely daft question.
I’ve a homebrew TrueNAS box and a headless BTFRS MDADM raid setup.
I wanted to map the drive on TrueNAS using mount.cifs so the share would be present as a ‘local’ folder without needing the intermediate device. Is this possible?
I was then looking to write a simple script to follow the copy along and as this is several TB (about 50) I rather wanted a more hands on ‘watch it as it works’ feedback than a log.
I tried, but ran into fstab errors, then permission denied and I felt I was doing more damage than progress. If anyone has done this, would they be kind enough to post a how-to?
“I wanted to map the drive on TrueNAS using mount.cifs so the share would be present as a ‘local’ folder without needing the intermediate device. Is this possible?”
Not quite understanding that part, specifically the intermedia device part, but if I am getting what are going for, you want the remote mount point to appear as if it where a local directory? I have done similar with SSHFS, created a folder locally and mounted multiple other systems in it, then shared that directory via SAMBA, so windows users could hop over to the share and peruse the remote file systems seamlessly.
Ah, my fault. I had included my us ecase and removed it as I felt i was waffling.
The goal, simply is to copy piles of dog show footage from one device to the other. As ‘the other’ device has very little in the way of configuration or management I wanted to map the other device’s SMB share to TrueNAS (treating it almost as a ‘normal’ Linux OS and copy it 1-1, rather than 1-2-1.
I’ve been using a Linux Mint device to copy the data from one locally mounted share to other using using rsync.
This gave me two network shares mapped to one third party (the intermediate machine) and the ‘third party’ did the copy. This, however, seemed ineffiicient considering the TrueNas box has something like 8 cores and 128gb of ram and a 10GB card and the other similar an dwe were relying on an old NUC to move the data about.
Basically, I want to run this command on TrueNAS:
“sudo mount -t cifs -o username=myuser //truenas/share/ /home/share”
What I would like to do is use the same command but on TrueNAS itself (as I can’t map it on the headless box), so the copy is point to point, as it were. I don’t want this share to appear in the TrueNAS UI, or for TrueNAS users to get to it in any fashion (if they can it’s not really important as there’s only a handful of users) It’s solely to copy the data from one server to the other.
Apologies for the confusion, my post wasn’t very clear.
Maybe I missed something, but is there any reason not to just use rsync to copy the data right from your btrfs source to the TrueNAS destination? Seems like you’d save a step.
Absolutely, if it is only data moving/mirroring, not live serving, I would not even consider any inter-device file share, rsync over SSH, schedule it as needed, and call it a day.
I enabled smb services in truenas, then from my pc’s fstab, I mounted the share in my home dir as ‘share’ From then on, I can rsync & read/write in that share.
None of the GUI services assist me in mapping a network share. They are not what I am looking to do.
I’m not sure if I’ve been unclear: I can mount the TrueNAS share without any problems on client machines. I want to mount a remote share - one on another machine - on the TrueNAS server.
Sorry if I’m not quite understanding, but I think the hindrance is figuring out what part is getting in your way. If you know the exact mount command you want, what’s stopping you from ssh-ing into TrueNAS and running it? Is it failing when you do? And if rsync would accomplish your actual goal, what’s the barrier to that?
Hullo tvcvt, I spent a good while bashing at it and came up with these instructions. I imagine more capable folk than I will say ‘well, isn’t that obvious’ but as I didn’t know I was a lot more procedural.
1. Either create or use an admin account on TrueNAS.
Credentials / User / Edit user /
Note uid and gid
ssh password enabled
Shell TrueNAS console
Save
2. Create mount point
Create directory in mnt using sudo
e.g sudo mkdir /mnt/myshare
Sudo chmod 777 that directory
3. Add share to map entry to fstab
Before moving on confirm a before and after of your fstab file. Break this and you won't boot.
Sudo nano /etc/fstab
# Description of what the entry does, such as what is below: user account used to map, IP address/name of device.
//[remote_device]/[remote_share_name] /mnt/[directory_name] cifs username=[username_used_to_access_remote_share],password=[users_password],uid=[uid_of_trueNAS_admin_user],gid=[gid_of_admin_TrueNAS_admin_account],noauto,rw,users 0 0
The [remote_device] is the IP or hostname of the remote share.
The uid and gid are of the admin user mounting the drive. Check what these are before entering the text.
4. Restart the daemon for the change to take. If you don't do this trying to mount the share - step 5 - will tell you that fstab has changed and to reload it.
Systemctl daemon-reload
5. Mount the share
Sudo mount /mnt/myshare
Test the directory has populated by creating a dud file in there through the UI on a client machine.
Ls -lsh the directory to confirm the correct location has been mounted.
Before moving on confirm a before and after of your fstab file.
6. Have the smb share mount automatically on boot
Make sure each command does what you expect it to from the console *first*. A blunder could muck up your booting at all so double and then triple check by using multiple comment 'commands'.
On the TrueNAS web UI, navigate to: System / Advanced settings
Locate Init/Shutdown Scripts
Now, commands seem to be run 'in order so get that right
First, add a comment for the fstab entry.
Add a name for the script, such as "Add description to fstab"
It is of type 'command'
In the command field enter: echo "#Map [mremote_share] to /mnt/myshare" >> /etc/fstab
This appends the content in between the double quotes (" ") into fstab.
The hash makes the content a comment, so this line isn't executable, but it still needs to go on a new line. If you've not use >> (two right chevrons) you'll overwrite the content of the file and break your system.
Set When to Post Init (after main startup)
Don't tick Enabled yet
Save
Now add another Init/shutdown script that adds the fstab entry to actually mount the remote share.
Type: Command
The Command field:
I recommend commenting it out the first time (prefixing # to the //IP.add.re.ss/) to ensure it isn't causing any other problems.
echo "//[remote_host]/[remote_share] /mnt/myshare cifs username=[remote_user],password=[remote_user_pass],uid=[local_uid],gid=[local_guid],noauto,rw,users 0 0" >> /etc/fstab
This appends the above - map the ip/sharename to the directory path using these credentials but for this user (uid, gid) to fstab
Set when to Post Init (startup)
Don't enable yet.
Save
If the share name is uppercase and you've used lower it won't work, so test.
When you're sure the command works, enable the start up command (I recommend enabling the comment first) and reboot the server.
7. Check fstab is properly populated after reboot.
Ssh back in and at the console:
cat /etc/fstab
If the mount point is not populated with the share, you may need to systemctl reload-daemon and then run sudo mount /mnt/myshare
I’ve not yet worked out why my rsync script isn’t able to run despite my chmod +x ing the file inside my home directory, but hey ho. I can run rsync manually per folder and shift the data about. The first batch of footage copied at around 500MB/s rather than the 43MB/s through the intermediary device.
Thanks to all for the advice, apologies for my not being clear.
I asked if mapping remote shares could be added to the TrueNAS UI as a feature request, but I must be the only person who didn’t know how to do it.
Save that and set permissions on the credentials file, chmod 600 because it contains sensitive plain text creds.
Then before you reboot mount -av to see if it works, if not why (so if there is an issue you do not get stuck in no boot)
Once confirmed, this will persist, if the remote share is not available on boot of this system, a mount -av will resume, or just reboot the NAS. with nofail, the system will not hang if it is not available.
Depending on what the CIFS share host is ruing it may be SMB2 so verify first and set 3.0 to 2.0 in fstab accordingly.
Much obliged GeneMoody-Action1, that’s very helpful, esp. regarding the nofail. I hadn’t considered that.
I’ll add in the credentials bit later on - at the moment the only person who can actually log in to (the) TrueNAS is me, but you’re right to properly secure it.
A bit of a reportage: rather than the 50MB I was getting I saw 970MB/s at one point in the copy, so many thanks for everyone.
Depends on how you test, because there are a lot of factors there, for instance copy 10g of data will go faster as 1 10g file vs 1000 10m files. Lots of things form protocol overhead to disk overhead etc. Iperf has options to simulate a lot of network conditions such as many parallel transfers, packet / data size. But the things other than the stack that will affect performance too will not come out in the iperf scans.
There is no magic calculation, hence xkcd: Estimation, but anything > 800Mbps for file transfer on a 1g ethernet is considered good.