03-03-2009 12:09 PM
03-05-2009 11:24 AM
We're having a similar problem. We recently bought a TeraStation PRO to use on a mixed Linux/Windows network. The Windows set up was easy but we have spent a lot of time trying to set it up with Linux. I must say that the omission of any reference to Linux in the manual is somewhat disappointing! Also, the Network - Workgroup/Domains page seems to be very Windows and Apple centric; where is the option for sharing on Linux? If there is someone from Buffalo listening, is there a missing Linux manual somewhere? :-)
One of the main reasons we invested in the TeraStation was to use it to house our CVS respository. Setting this up has proved to be very time-consuming. The CVS service runs on a Ubunutu box which has the TeraStation mounted as CIFS. However, CVS requires permission to perform chmod operations on the repository but it can't as the ownership of the TeraStation directory is set to nobody:nobody and whenever CVS attemps to perform an operation, it returns with an "operation not permitted" error. We would like to use the Terastation with our regular Linux users/permission. Alternatively, is there a way to set up users/groups on the TeraStation which would mirror our regular Linux users?
I have tried altering the share permissions in the TeraStation web interface but to no avail. I also wondered whether the permissions problem might be related to the CIFS mount; is it possible to mount the TeraStation as NFS?
Any help would be appreciated!
06-03-2009 03:38 AM
we are using a Terastarion TS-XL with the same restrictions. To have nfs without the the posibility to save files with the right user
rights is really disappointing. I'm a developer for embedded systems and i want to use the nas to backup my work. No chance at
the moment. Without a way to configure nfs to preserve the user rights, the terastation it is absolutely useless. It's not more than
an expensive brick for me. Hopefully this will be changed as sone as possible.
12-06-2009 09:33 AM
Bump! Same problem here. I bought one terastation for use with NFS, now it seem to be a very expensive paperweight.
There is a solution for nfs?
01-07-2010 04:00 AM
What kind of file system have you choose from the File System dropbox? It seems like a file system problem.
Let me know for additional help.
01-14-2010 09:30 AM
Acording to the manual you can only choose XFS for internal drives, so the filesystem is XFS (at least in my case)
I still own a fancy paperweight
04-13-2010 07:00 PM - edited 04-13-2010 07:21 PM
Well... if this can be any help to anyone, I've figured out a way to hack it so permissions stick. I noticed the permissions always reverted to the anon user (arh... what use is that for secure storage ?), so I figured there must have been some default setting in the firmware. It runs a custom linux... hummm. I was hoping to figure it out from the web interface sources, but it's perl, with japanese comments. And I'm lazy. :) So I figured a way through the linux startup scripts instead. Not for the faint of heart... some linux familiarity using NFS and vi is required.
This was done on :
Model Name: TS-RHTGL/R5
Firmware Version: 1.33 NFS
a) install latest firmware (works with 1.33 NFS), configure your tera and make sure to configure your NFS folders and perms. You might want to make sure the clients can map it first. (You need a samba front-end for the permissions to stick properly, so your clients should consist of samba services mapping those shares, themselves mounted via NFS)
b) get telnet access to your terastation box using one of those exploit tools you can find on the web (nas-central is a good pointer). Login into your box using telnet and the user root. I was a little impressed at the ease of doing this. But he, as long as these boxes are not located in a DMZ or a virus infected user network, works for me. (hint hint) Make sure to activate the telnet service at startup, I trust you can figure this one out. Otherwise, no sweat, telnet turns off on the next reboot and you need to re-hack it if access is needed.
c) ... here's where it gets sketchy... I noticed the /etc/exports file gets overwritten on nfs service starts by a compiled binary. Argh. so, modify /etc/init.d/nfs.sh, as follows, to, ahum, ditch the firmware overwrites of your NFS exports config. (which means you got to manually edit the file to remove the all_squash feature, you can also adjust your anon ids to your likings).
... snippet ... /etc/init.d/nfs.sh
# START of selt modification to be able to modify NFSD startup options
echo "[making a copy of /etc/exports, selt hack]"
cp /etc/exports /etc/exports.swapping
# follows is an original line from the tera script.
nas_configgen -c nfs
echo "[swapping back orig exports file from our copy]"
if [ -e /etc/exports.swapping ]; then
cp /etc/exports /etc/exports.bufalo_version
cp /etc/exports.swapping /etc/exports
echo "orig exports file swapped back! "
echo "failure to swap, perhaps the /etc/exports file was not there ?
# EOF of selt modifications
echo -n "Starting RPC portmap daemon:"
... end of snippet ...
look for the last line in the snippet to locate the modification location.
d) edit your /etc/exports file to your likings (man exports...)
- remove the all_squash option (this squashes the perms to the anon user, your first pain)
- remap the anon IDs to yours (99 is what it is ? wouah... old style!)
e) /etc/init.d/nfs.sh restart Your permissions will now stick ! :p
AS LONG as you use the data through a NFS-mapped-to-Samba share. Accessing the NFS share through unix will mess up the permissions (still haven't figured out why, probably that busybox/blackbox software or something with the ldap-posix user mappings on my clients.).
Nevertheless, using this procedure I successfully constructed a pair of domain controlers with a centralized terastation for the user's roaming profiles, with proper permissions and quite redundant, without any sort of heartbeat or ip aliasing. Works great from openbsd-samba-openldap setups, getting that to integrate with Linux should be the same.
Hint to the terastation developers; you should figure out how to integrate the openldap tools in your boxes, it would allow better integration of user accounts from samba-ldap setups. (And you can bypass the DC stuff entirely by polling the auth from ldap directly... ahhh....)
ALSO; concerning chown and chmod; they do not work. ;) even with the above hack. I suspect the blackbox software is busy getting confused with the userIDs... they end up skewed when writing files over the NFS protocole. But one way around that is to create the root shares on your NFS partition using the proper permissions in the first place. ie; from your NFS client box;
mount the drive and then sudo/su -u username mkdir username_share
the permissions will stick and so will the files created by the target users (through windows at least).
Hope this helps !
06-30-2010 02:53 PM
A simple search and replace with Perl will be a quicker way.......
In your /etc/init.d/nfs.sh after the nas_configgen -c nfs statement(should be around line 80) add
perl -pi -w -e 's/rw,sync,all_squash,anonuid=99,anongid=99,no_sub
then restart nfs with
This should keep your /etc/exports persistent
Credit for this hack goes to http://brain.demonpenguin.co.uk/2010/03/02/there-b