LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   NAS & break permissions (https://www.linuxquestions.org/questions/linux-server-73/nas-and-break-permissions-4175735405/)

sunjob 03-28-2024 08:20 AM

NAS & break permissions
 
good day!

original data
- NAS / OpenMediaVault-3.0.94
- hd1,hd2 - 2 HDD EXT4, equally connected/shared CIFS/SAMBA
- on hd1 the permits were badly 'broken'
- a remote connection to the NAS was made and permissions were corrected.

next, point by point:

fixing permissions hd1
Code:

cd /srv/dev-disk-by-label-hd1/hd1
chown -Rc sun:users ./
find ./ -type f -exec chmod 0664 {} +
find ./ -type d -exec chmod 0775 {} +
sync && reboot

after that, almost everything is OK, except for the 'unfinished execution-bit'.
hd2 - it's OK

disks are mounted in the same way
Code:

sudo mount -t cifs //nas/hdX /mnt/nas_smb_hdX -o username=sun,password=@XXX@,vers=1.0
Then, one by one, we go to the mounted directories and run the test:
- creating a text file, looking at permissions
- remove/set the 'x' bit, look

Code:

#
# hd1
#

# create text file
main$ echo "text" > text.txt
main$ ls -l text.txt
-rw-rw---- 1 sun users 0 Mar 28 16:37 text.txt

# clear bit x
main$ chmod -x text.txt
main$ ls -l text.txt
-rw-rwx--- 1 sun users 0 Mar 28 16:37 text.txt*

# set bit x
main$ chmod +x text.txt
main$ ls -l text.txt
-rwxrwx--x 1 sun users 0 Mar 28 16:37 text.txt*

# clear bit x
main$ chmod -x text.txt
main$ ls -l text.txt
-rw-rwx--- 1 sun users 0 Mar 28 16:37 text.txt*

#
# hd2
#

# create text file
main$ echo "text" > text.txt
main$ ls -l text.txt
-rw-rw-r-- 1 sun users 0 Mar 28 16:39 text.txt

# clear bit x
main$ chmod -x text.txt
main$ ls -l text.txt
-rw-rw-r-- 1 sun users 0 Mar 28 16:39 text.txt

# set bit x
main$ chmod +x text.txt
main$ ls -l text.txt
-rwxrwxr-x 1 sun users 0 Mar 28 16:39 text.txt*

# clear bit x
main$ ls -l text.txt
-rw-rw-r-- 1 sun users 0 Mar 28 16:39 text.txt

short summary:
on the 1st disk the bit is set and can no longer be removed
on 2nd behavior is predictable (set/reset as expected)

what is necessary: ​​bring the behavior of the 1st disk to normal (like the 2nd disk)

thank all!!!

p.s.

test on virtual-box with begin
Code:

main$ echo "text" > text.txt
main$ ls -l text.txt
-rw-rw-r-- 1 sun users 5 Mar 28 19:40 text.txt
main$
main$ chmod -x text.txt
main$ ls -l text.txt
-rw-rw-r-- 1 sun users 5 Mar 28 19:40 text.txt
main$
main$ chmod +x text.txt
main$ ls -l text.txt
-rwxrwxr-x 1 sun users 5 Mar 28 19:40 text.txt*
main$
main$ chmod -x text.txt
main$ ls -l text.txt
-rw-rw-r-- 1 sun users 5 Mar 28 19:40 text.txt
main$

and getfacl

Code:

#
# hd1
#
main$ getfacl NAS_SMB_HD1.txt
# file: NAS_SMB_HD1.txt
# owner: sun
# group: users
user::rw-
group::rw-
other::r--

main$ getfacl text.txt
# file: text.txt
# owner: sun
# group: users
user::rw-
group::rw-
other::---

#
# hd2
#
main$
main$ getfacl NAS_SMB_HD2.txt
# file: NAS_SMB_HD2.txt
# owner: sun
# group: users
user::rw-
group::rw-
other::r--

main$ getfacl text.txt
# file: text.txt
# owner: sun
# group: users
user::rw-
group::rw-
other::r--

1st file - native
2nd file - created from scratch
What do we have in the bottom line?!
Code:

other::---
# вместо
other::r--

what does this threaten us with?

lvm_ 03-28-2024 08:30 AM

Examine smb.conf file on the server - samba does some trickery with executable bits

sunjob 03-28-2024 08:41 AM

Quote:

Originally Posted by lvm_ (Post 6492511)
Examine smb.conf file on the server - samba does some trickery with executable bits

i'm can't touch & change SMB, but this content
Code:

root@nas:/etc/samba# cat /etc/samba/smb.conf
#======================= Global Settings =======================
[global]
workgroup = home
server string = %h server
dns proxy = no
log level = 0
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
syslog only = yes
panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = no
unix password sync = no
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY
guest account = nobody
load printers = no
disable spoolss = yes
printing = bsd
printcap name = /dev/null
unix extensions = yes
wide links = no
create mask = 0777
directory mask = 0777
map to guest = Bad User
use sendfile = yes
aio read size = 16384
aio write size = 16384
null passwords = no
local master = yes
time server = no
wins support = no
#======================= Share Definitions =======================
[hd1]
path = /srv/dev-disk-by-label-hd1/hd1
guest ok = yes
read only = no
browseable = yes
inherit acls = no
inherit permissions = no
ea support = no
store dos attributes = no
vfs objects =
printable = no
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
hide special files = yes
follow symlinks = yes
hide dot files = no
read list =
write list = "sun"
[hd2]
path = /srv/dev-disk-by-label-hd2/hd2
guest ok = yes
read only = no
browseable = yes
inherit acls = no
inherit permissions = no
ea support = no
store dos attributes = no
vfs objects =
printable = no
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
hide special files = yes
follow symlinks = yes
hide dot files = no
read list =
write list = "sun"

+

clarification: on the HD1 disk, during incorrect "maintenance" from the inside (under root), permissions were corrupted, so appropriate manipulations were made with the disk

this confirms that SAMBA has nothing to do with it, the problem initially stems from the access levels of the hard drive


All times are GMT -5. The time now is 04:25 PM.