Permissions on NFS share with TeraStation Pro Rackmount

[dlinder]

   

From reading this link:http://forums.buffalotech.com/buffalo/board/message?board.id=0101&message.id=5876&query.id=8378#M5876%20">TS-RHTGL/R5 F/W 1.33 NFS mount ownership problems it mentions the same problem we are having but I don't see a resolution to the posters problem. We are using Active Directory for authentication.

 

Here is our TeraStation information:

Model Name: TS-RHTGL/R5

Firmware Version: 1.33

 

I have tried using Active Directory for the Network Type and also Workgroup and Delegate Authority to External SMB Server. Neither of those options are allowing us to set file ownership and permissions on directories or files. 

 

We have the drive mounted from a Red Hat Enterprise Linux AS release 3 (Taroon Update 9) server.  We need to

 

df -h /nas

Filesystem            Size  Used Avail Use% Mounted on
pros-nas.prosrm.com:/mnt/array1/dumps
                      2.8T  1.3G  2.8T   1% /nas
23 > touch file.txt
 lux-app1: /nas/dlinder
24 > ll
total 0
-rw-rw-r--    1 nobody   nobody          0 Mar  3 12:06 file.txt
 lux-app1: /nas/dlinder
25 > chown dlinder:prosdev file.txt
chown: changing ownership of `file.txt': Operation not permitted

[robgregson]

   

Hi.

 

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!

 

[ropa]

   

Hi,

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.

 

Regards

ropa

[krasny]

   

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?

[elisa]

   

Hi,

 

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.

 

Elisa

[krasny]

   

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

[selt]

   

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! "

else

echo "failure to swap, perhaps the /etc/exports file was not there ?

fi

# 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 !

[silicon]

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_subtree_check/rw,sync,no_root_squash,no_subtree_check/g;' /etc/exports

 

then restart nfs with

 

/etc/init.d/nfs.sh restart

 

This should keep your /etc/exports persistent

 

Credit for this hack goes to http://brain.demonpenguin.co.uk/2010/03/02/there-be-buffalo-here/" target="_blank" rel="nofollow">http://brain.demonpenguin.co.uk/2010/03/02/there-be-buffalo-here/