Permission to delete files on SMB on GL-iNet MT-300N USB

I have a USB stick attached to my MT-300N that I have downloads from aria saved to. The stick is now getting full and I want to delete some of the files that I no longer need. When I access the USB over the network and get to the downloads folder I try to delete the files but it says:

You require permission from S-1-22-1-0 to make changes to this file.

And of course they won’t delete, none of the files are actively downloading or uploading in aria. And in the router settings I have share via WAN and Writable set to ON

Any ideas why I can’t delete?

This sounds like a Windows-security message. Is it possible that you’re using something like NTFS and there are permissions on the file that prevent its deletion? The file-sharing permissions on the router only say if write is allowed at all and generally don’t allow overriding file-level permissions.

This is intentional, as it allows, for example, “Joe” to be able to write/overwrite files that “belong” to Joe, but you to be able to lock-down certain files as “read-only” on the shares.

Yes. S-1-22-1-0 is a SID. You need to take ownership over the files as a Windows local administrator. This has nothing to do with the router itself. My guess is the user that added the files to the share is not the same as the user who is doing the deletion (i.e. the same computer & SID).

The best thing to do is locally mount the drive or SID, take ownership, delete the files, then re-attach it to the GL.iNET device.

Hmmm, I’m a little bit confused here.

Firstly, my MT-300N is on my home network, so there are no other users apart from me.
Secondly, all I did was format the USB as exFAT and plug it into the MT-300N and then set the File Sharing permission to writable from the admin GUI.

The files that were written to the USB were done so by the aria plugin that is installed on MT-300N (so they were not written by another device or user).

Looking at the doc here, setting the file sharing state to writable says the files can be edited - which I assumed meant write and delete? Am I wrong?

Two layers of security might be the confusion:

  • Joe tries to write an existing file on the shared drive
  • The sharing software sees a “write” request
  • Asks if Joe has the ability to write files, in general (yes)
  • Tries to write the file
  • The file system sees a “write” request
  • Asks if Joe has the ability to write this specific file (no)

Thanks for the reply jeffsf, but I really just want to find out if:

A: The setup I have is exactly the way other people’s devices are behaving?
B: If no, then why is my device behaving this way? And how to resolve it.
C: If yes, then what can I do on my MT-300N USB to easily change the permissions to get the behaviour that I want (do I install a plugin, do I have to put something into a command line somewhere).

The objective is just to have a no frills way of accessing the files that have been downloaded over the network to copy and delete them. I don’t want to have to remove the USB stick from the MT-300N and put it in my PC every time the folder gets full.

Appreciate the help regardless

I don’t use Windows, so I can’t comment meaningfully on how to manage Windows’ permission scheme.

If it were me, I’d make sure you’ve got kmod-fs-ext4 installed and format the stick using the Linux-native ext4 scheme (which doesn’t “know” about Windows users). Doing this probably means that a Windows machine can’t easily read/write the stick if you plug it in, but if you’re just using it as storage attached to our GL-MT300N, it should work well (perhaps even better than exFAT).

I can only confirm that just by activating the option to share files, I can write and delete files without problems, that if in units fat32 and ntfs connected to the USB port of the MT-300N-V2

I have been doing a bit of reading and experimenting and I think I need to be editing the smb.conf.template file

My file looks like this

netbios name = |NAME|
display charset = |CHARSET|
interfaces = |INTERFACES|
server string = |DESCRIPTION|
unix charset = |CHARSET|
workgroup = |WORKGROUP|
browseable = yes
deadtime = 30
domain master = yes
encrypt passwords = true
enable core files = no
guest account = nobody
guest ok = yes
invalid users = root
local master = yes
load printers = no
map to guest = Bad User
max protocol = SMB2
min receivefile size = 16384
null passwords = yes
obey pam restrictions = yes
os level = 20
passdb backend = smbpasswd
preferred master = yes
printable = no
security = share
smb encrypt = disabled
smb passwd file = /etc/samba/smbpasswd
syslog = 2
use sendfile = yes
writeable = yes

So far I’ve added this but it’s not improving the things…

[Aria Downloads]
path = /mnt/USBexFAT64G/download
read only = no
writable = yes
guest ok = yes
browseable = yes
create mask = 0777
directory mask = 0777

But I think I need to create a user or add a user?

Ok I have now solved this, this is what I did (with the help of very good friend)

Use WinSCP to edit /etc/samba/smb.conf.template

Go down the list and remove the line:

invalid users = root

Then add this lot at the bottom of the list:

[Downloads] <----- [The name you want to give the folder on the share]
path = /mnt/exFAT128GB/Downloads <-----/mnt/The folder name and path of your USB drive
valid users = root
read only = no
create mask = 777
force create mode = 777
security mask = 777
force security mode = 777
directory mask = 2777
force directory mode = 2777
directory security mask = 2777
force directory security mode = 2777

The final step is to set an SMB password using Putty. Login using the steps mentioned.

Then type:

smbpasswd -a root

Type a password of your choice (or use the same root password as I did). Confirm the password again.

Type exit to log out. Then reboot the router.

You should then go to Windows Network and see something like this:

Access the Downloads folder (or whatever you named it), a login box will appear, enter username as root and your password. You will now have write access to the folder.

Another possible option might be using the luci web interface which requires an additional couple of apps to be installed.

There are some pretty significant security implications about doing this.

There are good reasons why services run with their own users and groups, rather than as root. Restricting read/write access is one of them.

Making sure ownership of the files is properly handled within Samba is a much better approach.