You are not logged in.
Hi,
I am unable to delete files mounted between two Arch Linux machines (upgraded both just now) as a guest user. Everything else works (create file, edit file, move file to other location on share, rename file, delete folder). But I am unable to delete files. When trying to move a file to e. g. /tmp, it gets duplicated but not removed on the source. There is no error when trying to delete a file, it just stays there like nothing happend..
This setup used to work including deletion as a guest user. I am unsure when exactly it broke..
When using the share with a user, everything works as expected.
This is the relevant snipped of my smb.conf
[global]
map to guest = Bad User
idmap config * : backend = tdb
mangled names = no
[media]
create mask = 0644
force user = mediauser
guest ok = Yes
path = /zfspool/media
read only = No
I already played around with some settings and also moved the share off the zfs pool to my btrfs root, but no success, the behavior is the same.
Thanks for any ideas :-)
edit:
this is how I mount the share for testing:
mount -t cifs -o rw,guest //<server>/media /media
edit2:
okay when settings 777 permissions on the media folder on the server, deleting works. But I never had these permissions set at the time it worked with guest. Weird.. In my logic, the guest user should have all permissions of "mediauser" because of the force user setting, therefore also be able to delete files. Instead, the guest user seems to map to another user, therefore the o-rwx settings enables deletion... Hm..
Last edited by cryptoluks (2020-10-16 10:51:53)
Offline
Have you learned more about this issue? It seems to have popped up for me with the latest Samba package release, but I don't see anything obvious in the 4.13 release notes that would lead me to expect this behavior.
Offline
Any update?
I seem to be hit by the same issue - it used to work a few weeks ago.
The problems seems to be with "force user = scanner" and "force group = scanner" in sbm.conf, which I use so that all created files are owned by a single user.
The samba clients (they log in using their own username&password) can create and modify files, but cannot delete them.
I do not have any sticky bit on the SMB share directory on the server.
The "scanner" user on the server can delete the files.
P.S.2 Deleting files works when I set "force user" to the same username which is used by the samba client to log in (and when I modify the ownership of the shared directory to that very same user).
P.S.2 As a workaround, I set world writable bit to the shared directory ("chmod o+w /path/to/share/Scanner") and continue to use "force user = scanner".
--
Milan Knizek
http://knizek.net
Offline
I am also seeing this issue with samba 4.13. I rolled back to 4.12 but am surprised such a serious bug has made it to the stable release!
I also am using "force user" so there's another clue to the trouble.
Offline
Same issue, using force user. Downgrading to 4.12 is the only solution that has worked for me.
Offline
This maybe? is the BUG: https://bugzilla.samba.org/show_bug.cgi?id=14471
Last edited by Zeqadious (2020-12-28 16:27:22)
"Till shade is gone, till water is gone, into the Shadow with teeth bared, screaming defiance with the last breath, to spit in Sightblinder's eye on the Last Day"
Offline
I had the same issue.
Try setting your folder permisssions to
chmod 777 <folder-name>
on the parent folder of the file you are trying to delete and see if you can delete the files inside it.
If that works add this to the smb.conf so newly created folders will have the correct permisssions
directory mask = 02777
You will have to change all existing folder permissions on your share using the find command.
find -type d -exec chmod 777 {} +
Offline
I have found and fixed this bug in Samba master. The bugid is:
https://bugzilla.samba.org/show_bug.cgi?id=14617
There's a patch available in the bug report. I need to add a regression test to make sure we don't break this again but if people want to try the fix it's available.
The reason the bug made it into the release is it triggers an OS-level EACCES permission denied, which is currently very difficult to test with our regression test suite that relies on being able to run as a non-privileged user (non-root) which means it has to fake changing the uid/gid of the process. Underneath it all it's still running as the invoking user. I have an idea on how to test this and I'll try and get this test written up next week.
Cheers,
Jeremy Allison,
Samba Team.
Last edited by jra (2021-01-23 05:56:26)
Offline
I have found and fixed this bug in Samba master. The bugid is:
https://bugzilla.samba.org/show_bug.cgi?id=14617
There's a patch available in the bug report. I need to add a regression test to make sure we don't break this again but if people want to try the fix it's available.
The reason the bug made it into the release is it triggers an OS-level EACCES permission denied, which is currently very difficult to test with our regression test suite that relies on being able to run as a non-privileged user (non-root) which means it has to fake changing the uid/gid of the process. Underneath it all it's still running as the invoking user. I have an idea on how to test this and I'll try and get this test written up next week.
Cheers,
Jeremy Allison,
Samba Team.
Thanks for fixing this, and letting us know. It's working perfectly for me.
Offline