I have an SMB drive mounted on my fedora system. There are some old files that I saved on the SMB back when I was using Windows.
I went to do some spring cleaning and deleting old stuff. The filed deleted fine but are now stuck in the trash folder. The owner is root and I cannot delete these file.
This is the output of that command. I though it might be something about the way it is mounted in fstab. but I am new to Linux and don’t know very much.
I probably put noperm on there to fix some access problem I was having. But most things I do in linux I do not understand the reason. It’s usually something I find on the internet that solves some problem mysteriously.
File permissions on a CIFS share are one of the more complex things to manage.
One thing to be aware of is that changes in that /etc/fstab file do not take effect immediately. You might need to unmount the filesystem (sudo umount /mnt/tnas), tell the service manager to rescan the configuration (sudo systemctl daemon-reload), then mount the filesystem again (sudo mount /mnt/tnas). You can verify what settings are active by running the mount command without any parameters.
Another thing to be aware of is that misconfigurations in that /etc/fstab file can prevent your system from booting. For a mount point such as this that is not critical to the system, it is best to include nofail in the list of mount options so that your PC will continue booting, even if that filesystem cannot be mounted for whatever reason (e.g. your NAS device is turned off).
While you are at it, I think there should be two leading forward slashes in the first field for CIFS shares (i.e., //172.16.0.201/SAS6T/user). At least, that is what the man page states:
The mount.cifs utility attaches the UNC name (exported network resource) specified as service (using //server/share syntax, where “server”
is the server name or IP address and “share” is the name of the share) to the local directory mount-point.
Assuming the noperm setting is active on that mountpoint (i.e., it shows in the output of the mount command), I think it must be your device that is blocking the deletion of those files. Normally, both the remote device and your Linux client will verify that the permissions allow an access, but with that noperm setting, the Linux client should not be checking the permissions at all. If the NAS device is refusing the operation, you will have to change the settings on the NAS device or maybe connect to it with different SMB credentials.
I’m not familiar with your NAS device, but does it have a web interface if you browse to https://172.16.0.201/ with your web browser? If so, can you use that web interface to reset the permissons and/or ownership of the files you are trying to delete?
//172.16.0.201/SAS6T/user on /mnt/tnas type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=user,uid=0,noforceuid,gid=0,noforcegid,addr=172.16.0.201,file_mode=0755,dir_mode=0755,iocharset=utf8,soft,nounix,serverino,mapposix,noperm,reparse=nfs,nativesocket,symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
My nas is TrueNAS running as a virtual machine (looks like it is FreeBSD) on a Proxmox server.
I will go poke around there and see what i can figure out.
The manual page says this but it still confuses me.
access based share enum (S)
If this parameter is yes for a service, then the share hosted by
the service will only be visible to users who have read or write
access to the share during share enumeration (for example net view
\\sambaserver). The share ACLs which allow or deny the access to
the share can be modified using for example the sharesec command or
using the appropriate Windows tools. This has parallels to access
based enumeration, the main difference being that only share
permissions are evaluated, and security descriptors on files
contained on the share are not used in computing enumeration access
rights.
I don’t know about how the NAS treats hidden folder. But I just tried to create .test folder and that worked and then I deleted it and that worked too.
File permissions have several “layers”. You have to have access at every level/layer in order for the access to be granted. Remotely mounted filesystems have even more layers.
The Linux/Unix ownership and mode bits are one layer.
ACLs (access control lists) are another layer. Try running getfacl /mnt/tnas/.Trash-1000/files/somefile to see what ACLs are set.
Share-level permissions are yet another level/layer.
And SELinux labels are another layer.
If you cannot find the problem by inspecting the permissions on the files themselves, you might try watching the logs while you do whatever is being blocked. Run sudo journalctl -f in a separate terminal window to monitor the logs.
Also, you probably need write access to the parent directories, not just the file itself, in order to delete the file.
I can create files and folders anywhere in .Trash-1000/ and it’s subfolder, even the folder that I cannot delete, but I cannot delete the files that I sent to this location via the “send to trash“ button.
I can also change the names of the folder that I cannot delete but I cannot change the names of any files in those folders.
Ah, that might be why the rm command is failing as well. If any part of the path or the filename has spaces in it, you will need to quote the parameter. For example:
rm "/home/Iselda Corny/my file"
Without the "s, the above rm command would try to delete three files – /home/Iselda, Corny/my, and file.
P.S. If the parameter needs to contain a double quote ("), then you would either have to use single quotes (') instead of double quotes, or you can prefix the double quote with a backslash (\) to tell Bash (the command interpreter) not to treat the quote as a special character.
Unfortunately, you’ve found another nuance. The asterisk (*) loses its special meaning when it is inside a quoted string. If you want to use both an asterisk and a quoted string, you have to place the asterisk outside the quoted string. For example:
sudo rm -rf "/mnt/tnas/.Trash-1000/files/"*
BE CAREFUL with rm -rf and that *! If you get it wrong, it could delete everything very very quickly. [1]
P.S. Just in case you are curious about it, the command interpreter will strip the first layer of quotes before it actually runs the command. So something like echo "one two" will run the command with one parameter containing a space (i.e, one two). Something like echo "one two"three"four five" will still call the command with only one parameter (i.e., one twothreefour five). But echo "one two"three four"five six" would count as two parameters (i.e., one twothree and fourfive six). The unquoted space is treated as a separator for parameters.
P.P.S. In general, you are probably better off cding to the directory where you want to delete the files rather than running that rm -rf command as shown above. So, do this instead:
cd /mnt/tnas/.Trash-1000/files
ls # to be sure you are where you think you are and you see only the things you want to delete
sudo rm -rf *
A little safer still would be not to use the * with rm -rf, but delete the parent directory by its name instead.
