0

I have a NAS on which years ago (I was using a Linux box at the time) I copied some files mounting it as a NFS share.

Years later... few days ago, I tried to access to the same files/folders from a Windows machine via SMB. Result: permission denied. I cannot access, move, delete, nothing. Even with admin privileges. I tried to access from a Mac machine (still with SMB), confident it's a Unix under the hood... same result. Even with root.

I then tried from a Linux (still with SMB) and again same results. Then I switched to NFS mount and, here we go, full access with no issue.

I tried to investigate the reasons, but I still have no clues.

I created some copies of a sample folder:

enter image description here

STUDY is the original one: note it has extended attributes, and I thought that was the issue since all the other file and folders I can manage with SMB don't have them.

So first thing I did was to create a copy called "STUDYtest" and try to remove the attributes with the command:

sudo setfacl -Rbk STUDYtest/

Indeed it removed the extended attributes, as you can see from the screenshot above, but still that folder and files within are not manageable via SMB (in the process it also lost the write permission for others... don't ask me why!).

I then tried to copy the folder to another location, without preserving the properties, with the command:

cp -r --no-preserve=mode,ownership STUDY/ /home/alberto/

Then I renamed it to STUDYnopreserve and copied it back to the NAS and this time, I can manage it via SMB from Windows.

I don't understand why though! To me they look identical:

enter image description here

enter image description here

They both have extended attributes, the only difference being the owner?

I'd like to avoid to copy elsewhere and back in all the data (3+TB) and, most importantly, I'd like to understand the reason behind.

Can someone please point me in the right direction or suggest the next test to do?

1 Answer 1

0

I made other tests and found out that my previous workaround, to be fully functional, needed the copy (with the no-preserve option) to a different location/drive and then back to the original one (if data needed to stay in the same place). Otherwise the contents were accessible but the remote SMB user couldn't modify or remove them.

I didn't investigate further why, because in the meantime I've found what I think is the final solution, and it's far simpler and easier than anything else I had tried before.

Simply:

sudo chmod -R 777 /path

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .