Windows ACL ownership mechanism  #

Every object has an owner, whether the object is in an NTFS volume or in Active Directory Domain Services (AD DS). The owner controls how permissions are set on the object and to whom permissions are granted.

An administrator who needs to repair or change permissions on a file must begin by taking ownership of the file. By default, the owner is the entity that created the object. The owner can always change permissions on an object, even when the owner is denied all access to the object.

File name length limitations in QSM #

In QSM3 and QSM4 systems, the file name length limit for NAS is 255 bytes. One English letter occupies 1 byte, while one Chinese character occupies 3 bytes. For conversions of other languages into bytes, please refer to the following website.

https://mothereff.in/byte-counter

How to delete a share with WORM enabled from the UI? #

When a share is enabled with WORM protection and the files are set to be protected for two days, all files within the share must be deleted before the share can be removed from the UI. Therefore, the inability to delete the share is in line with our software design specifications. We recommend deleting all files in the share that exceed the WORM protection period, then attempt to delete the share from the UI again.

Why does the newly created share occupy space with QSM4? #

After creating a share, the system will need around 0.7–0.8% of the pool’s space to store metadata. The exact percentage can be referenced in the table below.

Share Size	Metadata Space Usage (%)
1G	3.8%
5G	1.3%
10G	1%
20G	0.88%
30G	0.82%
40G	0.79%
50G	0.78%
100G	0.75%
10T	0.71%

Why can’t you delete the share when WORM setting is expired? #

Please check if there are any files in the share. The WORM software is designed as follows:

When deleting a share in a volume with WORM enabled, the system will check for the presence of data/files:

• If there are no data/files in the share, the system will allow the deletion of the share.
• If any data/files still exist in the share, the system will not allow the deletion operation.

CIFS share with AD read-only user still able to create folders and files #

1. Create a CIFS share and add the share host.
2. Clear net use connections, then enable WinACL.
3. Join the AD domain, and then add the AD user permissions to the share.
4. Log in with the local admin account, add the AD administrator account, log out, and then log in with the AD administrator account.
5. Add the AD domain user test1 and configure the permission as read-only.
6. Log out of the AD administrator account, and then log in with AD user test1.
7. Attempt to create folders and files –> Fail. The permission is set to read-only, but folders and files can still be created, and four folders will appear.

This is a known SMB issue caused by a permission conflict (qpermission > RO and WACL > full control). Please note the following two points:

1. Do not use the AD server for testing.
2. After logging in as local admin, the WinACL permission must first be adjusted to This folder, subfolders, and files to ensure that permissions are not unintentionally.

Windows ACL is set to read-only, but File Manager and CIFS show different permission behaviors.  #

After setting the account to read-only, the observed behavior is as follows: when accessing via CIFS (Windows to NAS), write operations are not allowed, but writing is still possible through File Manager.

Since CIFS (Windows to Windows) also allows write operations under the same condition, this is not considered an issue at this stage.

For Matrix: QSANOS-CIFS means CIFS (Windows to NAS), Windows means (windows to windows CIFS)

Permission	Type	QSANOS-CIFS	QSANOS-File_manage	Windows
RW	File	Creation succeeds / Can read / Can edit / Can delete	Creation succeeds / Can read / Editing not supported / Can delete	Creation succeeds / Can read / Can edit / Can delete
RW	Folder	Creation succeeds / Can read / Can edit / Can delete	Creation succeeds / Can read / Editing not supported / Can delete	Creation succeeds / Can read / Can edit / Can delete
RO	File	Creation fails (copying a file to the path succeeds) / Can read / Cannot edit / Cannot delete	Creation succeeds / Can read / Editing not supported / Cannot delete	Creation succeeds / Can read / Can edit / Can delete
RO	Folder	Creation fails / Can read / Cannot edit / Cannot delete	Creation succeeds / Can read / Editing not supported / Cannot delete	Creation succeeds / Can read / Can edit / Can delete
Deny	File	Cannot read	Cannot read	Cannot read
Deny	Folder	Cannot read	Cannot read	Cannot read

Resolving garbled filenames containing special characters #

1. When a filename contains special characters such as \ / : * ? " < > |, it may appear as garbled text when the share is accessed through CIFS using Windows File Explorer.
2. To view the filename correctly, connect to the share via FTP and set the character encoding to UTF-8 (Unicode code page 65001).