NAS/Artico

Use the links below to access NAS/Artico Qwikipedia content. If you have additional NAS/Artico content to share, please feel free create a new page under this topic and add your content there, so that others can review, contribute to, and benefit from your information.

 

Notes

 

So to add an ACL you use the following command

 

# chmod -R +a  'ACL' <dirname>

#ACL for different levels of access

FULL

list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit

 

Modify

list,add_file,search,delete,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit

 

Read/Execute

list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit

 

#chmod -R +a full /stornext/win/rawVideo/

 

The modify ACL is interesting if you want to give full access to a group of files/folder but don't allow them to change the ACL.

 ref~ Alain

 

 ~~~~ 

 

1 - Remove existing ACLs from all folders

From a Mac, use the terminal command:   

chmod -R -N <directory>

This command usually does a good job of recursively drilling down, but it’s always a good idea to double check deeply nested folders and ensure the ACLs are gone - 

ls -lde <directory>

ls -le <file>

To verify that there are no ACLs

 

2 - Remove Sticky Bit from all directories

On a Mac, use terminal command:

chmod -R g-s <directory>

This command usually does a pretty good job of recursively drilling down, but it’s always good to double check deeply nested folders and ensure the sticky bits are gone

ls -ld <directory>

To verify that there are is no ’s’ anywhere in the POSIX permissions

ls -ld <directory>

ls -l <file>       

 

3 - Set new POSIX permissions on existing folders:

Set POSIX permissions to 770 or 775

From the Mac - use the following terminal command

chmod -R 775 <directory>

This command usually does a good job of recursively drilling down, but it’s always a good idea to double check deeply nested folders to ensure the new POSIX permissions have been set. Use:

ls -ld <directory>

ls -l <file>

Set new POSIX owners/groups:

Owner: root - full access

Group - <domain directory group> - full access

Everyone else: read-only or no access

Use the Mac Terminal command:

chown -R <owner>:<domain group> <Directory>

This command does a good job of recursively drilling down, but it’s always a good idea to double check deeply nested folders to ensure the new owner/group has taken.  Use:

ls -ld <Directory>

ls -l <file>

 

4 - Change UMASK on all Mac systems to 002

This varies dependent on Mac OS version:

https://support.apple.com/en-ca/HT201684

Create a file on the Mac and make sure the file has the correct permissions:

Owner: Read/Write

Group: Read/Write <— this should be the <Domain Directory> Group

Everyone Else: No Access

5 - On each Mac - create a file and examine the POSIX permissions -

Make sure the group matches and has Read/Write access to the file

In Andy’s screen shot today there were differing POSIX permissions on each system:           

James K. - 775

Scott O. - 755

Andy Mac - 777

Scott G Mac - 777

James W. Mac - 755

Problematic machines are bolded, but all machines should be creating files with 775 or 770 permissions.

On the Mac Command line use:

ls -ld <directory>

ls -l <file>

 

6 - Verify that in the file system configuration, from the StorNext MDC GUI - 

Configuration > File Systems > Edit > Advanced Parameters > LDAP

Unix File Creation Mode on Windows - 775

Unix Directory Creation Mode on Windows 775

Unix Nobody UID/GID - mapped to appropriate Unix GID/UID users

Unix ID Fabrication on Windows - Enabled

Configuration > File Systems > Edit > Advanced Parameters > Features

Windows Security - enabled

Enforce ACLS - enabled

Use Active Directory SFU - enabled

Changing these settings will require a restart of the file system - it is recommended all clients have unmounted the file system before it is restarted.

 

7 - Apply new ACL to Root directories from the Mac command line:

Apply to appropriate domain groups - and give full control -

Make sure inheritance flag is set:

chmod -R +a "group:MDHDomain Users:allow:list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit" <directory>

Note in the above command "MDHDomain Users” must be replaced with correct  customer domain group

Create a file from the Mac and examine the file in terminal

ls -le /path/to/file

Verify the Mac can read the ACL doesn’t display as a hexadecimal number.

Do this from each Mac client to ensure no outliers.

Create a folder from the Mac and exam that folder as well:

ls -lde /path/to/folder

Likewise ensure that the ACL shows up correctly and doesn’t display as a Hex 

number.

Do this from each Mac client to ensure no outliers.

 

Once again - the chmod command usually does a good job of recursively drilling down but it’s a good idea to check deeply nested folder and see that they have the appropriate ACL applied:

ls -lde <directory>

ls -le <file>

 

8 - On a Windows Machine 

Create a file 

Verify the ACLs are read by the Windows system using the Windows GUI

Create a folder and verify the same

Go to a Mac system and examine the files/folders above

Verify that the POSIX permissions line up with what was set in set 6 above 

Verify that the Mac can read the ACL and it doesn’t show up as a Hex number

 

 

Sample setting ACL on local users;

sudo chmod +a "group:everyone allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit" /Volumes/Saturn/

 

 

Note by Chuck Forry on 05/13/2017 10:21 AM

 

http://qsupport.quantum.com/kb/flare/Content/stornext/SNNAS_Docsite/NAS%20CLI%20Guide/NAS_CLI_KerberosKeytab.htm

 

 

"If a Kerberos keytab has already been prepared for your StorNext NAS Gateway, you can configure it as an authenticated user without needing to specify an administrator user and password."

 

You can make and import a keytab like this…

The ‘kinit’ creates and imports in the one command.

 

[root@cx-node1 ~]# kinit Administrator@SPS.LAB

Password for Administrator@SPS.LAB

 

then list it like this

 

[root@cx-node1 ~]# klist

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: Administrator@SPS.LAB

 

Valid starting     Expires            Service principal

07/26/16 09:54:59  07/26/16 19:54:50  krbtgt/SPS.LAB@SPS.LAB

        renew until 07/27/16 09:54:59

 

 

 After the keytab has been imported, enter the following command to specify the keytab as the authenticated user for the LDAP server:

auth config ldap keytab <ip_addr|host> <ldap_domain> <kerberos_realm>

Note by Chuck Forry on 05/13/2017 10:03 AM

 

From: Carlo Ambrosio 

Sent: Tuesday, November 15, 2016 8:33 AM

To: DL-SN-SES; DL-Service - SW Support

Cc: Alain Renaud

Subject: NAS DR

 

Guys,

 

I just put together the steps to do a NAS DR in case the file system where the NAS cluster files were stored is lost (for example RAID issue) or the .snnas directory is accidentally deleted.

 

On the Node where we have the NAS VIP interface running or actual Master Node:

 

From bash cli:

# initctl/systemctl stop snnas_controller

# /usr/local/quantum/bin/snnas_service.py stop

# kill -9 `cat /var/run/ctdb/ctdbd.pid`

# initctl/systemctl start snnas_controller

 

From panshell cli:

> reg set nas.cluster.join = 0

> reg set nas.cluster.join_complete = 0

> reg set nas.cluster.master = 0

> reg set nas.cluster.snfs_root = ''

> system restart services all

 

Do the same on the secondary node.

At this point you can just recreate the cluster, on the master node:

 

>nascluster enable master IP /mount/point

>nascluster enable node IP

>nascluster join /mount/point

 

On the secondary node:

 

> nascluster join /mount/point

 

 

For the NAS-VIP there is no much we can do, as soon we break the cluster, the NAS will ignore that value, so the best is to recreate a cluster using a different file system.

 

The benefit of using this procedure is that we won't need to join manually to the ADS again.

 

I also opened a Documentation bug: http://bo.quantum.com/bugzilla/show_bug.cgi?id=65557

 

Feel free to add customers if necessary.

 

Thanks,

Carlo

Note by Chuck Forry on 05/13/2017 10:01 AM

 

 

Slow Copy over SMB with Finder when copying a lot of files.

Have a look to this bug: http://bo.quantum.com/bugzilla/show_bug.cgi?id=62968

Be careful about changing these parameter you need to use the NAS cli to do so and you cannot set the socket option you just mentioned.

 

Bug 62100 - share change smb global socket options silently ignores some options

 

The  case sensitive is a very good idea.

 

We are also tracking slowness with Finder and NAS via bug Bug 62968 - Slow Copy over SMB with Finder when copying a lot of files.

 

 

Finally Can someone update the escalation page so that we have the NAS version when requesting NAS help. 5.3.0 Artico can run NAS 1.2.1 or 1.2.3 if you run 1.2.1 you need to at minimum upgrade to 1.2.3

 

to check which nas version

 

rpm -qa | grep snfs-nas

 

One more thing…

 make sure that the mount option of the Stornext Filesystem on the Artico system makes sense. Something like this should be a minimum

 

cachebufsize=512k,buffercachecap=4096,dircachesize=32m

  ref. Alain SUS

 

~~~

 

 Subject: RE: Artico Escalation To SES From SPS: SR3696168, Customer:WALT

| DISNEY COMPANY -- slow updates in Finder and on CLI on Mac's connected via

| SMB to Artico share, Serial Number: EW1538CKG00988

|

| Hi Carlo

|

| Thanks a lot. I'll try the fix 1 and will let you know.

|

| 1 - setting the following tunable in smb.conf

| socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192

| case sensitive = yes

 

 

Note by Chuck Forry on 06/17/2016 11:18 AM


This page was generated by the BrainKeeper Enterprise Wiki, © 2018