What I would like to do is mount some workstations special shares in say /mnt/WorkStation1 and /mnt/WorkStation2. I did this and added to fstab so they'd get remounted. however my lines in smb.conf seems to be overwritten.

 

I read about smb-extras.conf (though I don't have it on my system) and was wondering how I utilize/create it. My lines in smb.conf get's removed so I assume if I add smb-extras.conf in there it'll also get removed?

 

Or is there another way to make my changes to smb.conf persistent?

Simply create the file (smb-extra.conf) using a Unix line-ending friendly editor.

 

It should be contained on your flash drive's "config" folder. It will be persistent and changes done in there will survive reboots. Note the file name, it is smb-extra.conf and NOT smb-extras.conf.  Once again, the full filename is "/boot/config/smb-extra.conf" on a running system.

 

Can something similar be done for files in the home folder and other places that also get wiped?

IF you need to maintain other files between reboots, you need to keep copies of these files on the persistent storage (e.g. on the USB at /boot/my_persistent_files)  and copy them to the appropriate place on reboot (e.g. by updating the go script to copy the files). 

 

You would also need a script/process to copy the files from non persistent storage to persistent storage when they change, or before the server is shutdown.

There is a difference between MOUNTING a disk and creating a samba share to a disk.

 

If you are planning to mount a non-array disk, you can use unmenu to do it for you, or you can put some commands in your "go" files to do it automatically on each boot.

 

You can create a custom Samba share either to a disk that you manually mount or to a disk that is already mounted.  Custom Samba shares let you create shares to specific subdirectories on specific disks, and also allow you to implement security on non-user shares.

 

If you go to a telnet prompt and enter the command:

 

testparm -s

 

you will see all of the shares that unRAID creates for you.  The top of the file sets defines some global values followed by each of  the share definitions.  You can cut and paste a sample share definition from this output to your own smb-extra.conf file.

 

Note that different versions of unRAID use different Samba setups.  In particular, 5.0 b2 is very different.  The "force user = root" setting is not used.  Also the create mask and directory masks have changed. When you create your shares, use the convention of your version of unRAID.  When you update to a new version you may need to revisit the Samba structure to remain consistant.

IF you need to maintain other files between reboots, you need to keep copies of these files on the persistent storage (e.g. on the USB at /boot/my_persistent_files)  and copy them to the appropriate place on reboot (e.g. by updating the go script to copy the files).  

 

You would also need a script/process to copy the files from non persistent storage to persistent storage when they change, or before the server is shutdown.

 

Why not simply store the files on the say "/boot/customized" and then use ln to link the files to the appropriate place, that way any changes to them will end up on the flash.

 

@bjp999: I just mount some not very important shares from my workstation through the unraid server so I've simply put the creating and mounting in go. Then ofc smb-extra.conf to share what I created in go.

Why not simply store the files on the say "/boot/customized" and then use ln to link the files to the appropriate place, that way any changes to them will end up on the flash.

 

@bjp999: I just mount some not very important shares from my workstation through the unraid server so I've simply put the creating and mounting in go. Then ofc smb-extra.conf to share what I created in go.

 

The decision whether to copy files to the tempfs or link them to the flash may need to be on a case by case basis.  You don't want to put files that are frequently updated on the flash, becuase of limited write cycles.  But you are right, if you need to keep the updates and they are not updated frequently, it is better to link them to the flash.

 

One thing we were hoping to get from 5.0 was "events" that you could hook to do certain things.  For example, if you had a hook when the array was being stopped, you could copy a file from the tempfs to the flash (or somewhere on the array) when needed.  That way, for frequently updated files that you'd like to maintain on the flash but don't want to take the frequent intermediate updates, you could just copy it to tempfs in the "go" script, and copy it back to the flash on the "stop array" hook.  But this feature is not currently available.

That's not correct.

 

When you hit "stop" array button via emhttp it does send an event "stopped" in 5.0 beta 2. Currently the event is hooked into one that simply echos it to the syslog. One can easily hook into it there. The full filename is /usr/local/emhttp/emhttp_event. Here is a typical stop array event series produced from this feature.

 

Nov 10 11:05:43 reaver emhttp: shcmd (58): /usr/local/emhttp/emhttp_event stopping_svcs

Nov 10 11:05:43 reaver emhttp_event: stopping_svcs

Nov 10 11:05:43 reaver emhttp: Stop CIFS...

Nov 10 11:05:43 reaver emhttp: shcmd (59): /etc/rc.d/rc.samba stop | logger

Nov 10 11:05:43 reaver emhttp: Stop NFS...

Nov 10 11:05:43 reaver emhttp: shcmd (60): /etc/rc.d/rc.nfsd stop | logger

Nov 10 11:05:43 reaver emhttp: Spinning up all drives...

Nov 10 11:05:43 reaver emhttp: Sync filesystems...

Nov 10 11:05:43 reaver emhttp: shcmd (61): sync

Nov 10 11:05:54 reaver emhttp: shcmd (62): /usr/local/emhttp/emhttp_event unmounting_disks

Nov 10 11:05:54 reaver emhttp_event: unmounting_disks

Nov 10 11:05:54 reaver emhttp: shcmd (63): umount /mnt/user >/dev/null 2>&1

Nov 10 11:05:54 reaver emhttp: shcmd (64): rmdir /mnt/user >/dev/null 2>&1

Nov 10 11:05:54 reaver emhttp: Unmounting disks...

Nov 10 11:05:54 reaver emhttp: shcmd (65): umount /mnt/disk1 >/dev/null 2>&1

Nov 10 11:05:54 reaver emhttp: shcmd (66): rmdir /mnt/disk1 >/dev/null 2>&1

Nov 10 11:05:54 reaver emhttp: shcmd (67): umount /mnt/disk2 >/dev/null 2>&1

Nov 10 11:05:55 reaver emhttp: shcmd (68): rmdir /mnt/disk2 >/dev/null 2>&1

Nov 10 11:05:55 reaver emhttp: shcmd (69): umount /mnt/disk3 >/dev/null 2>&1

Nov 10 11:05:55 reaver emhttp: shcmd (70): rmdir /mnt/disk3 >/dev/null 2>&1

Nov 10 11:05:55 reaver emhttp: shcmd (71): /usr/local/emhttp/emhttp_event stopping_array

Nov 10 11:05:55 reaver emhttp_event: stopping_array

Nov 10 11:05:55 reaver emhttp: shcmd (72): /usr/local/emhttp/emhttp_event stopped

Nov 10 11:05:55 reaver emhttp_event: stopped

<snip>

One thing we were hoping to get from 5.0 was "events" that you could hook to do certain things.  For example, if you had a hook when the array was being stopped, you could copy a file from the tempfs to the flash (or somewhere on the array) when needed.  That way, for frequently updated files that you'd like to maintain on the flash but don't want to take the frequent intermediate updates, you could just copy it to tempfs in the "go" script, and copy it back to the flash on the "stop array" hook.  But this feature is not currently available.

 

How does unraid handle a directory that it doesn't think belong on disk1? I don't share my disks outwards only the user shares. Could I (for files with intense usage) make a hidden directory on say disk1 and add the files (and link ofc) to that place or would unraid think it's supposed to be a usershare and share it?