SAMBA ERROR: cannot create regular file `~/tux016.pdf': Permission denied

mokele · 02-04-2007, 06:05 PM

**SOLVED**
This first post was edited 3 times. The last time Is named
"UPDATE 2/21/2007", thats how I solved the issue.

I can read/browse the share but I can't write. I get the error:

bash-3.1$ cp tux016.pdf ~/smb/every
cp: cannot create regular file `/home/west/smb/every/tux016.pdf': Permission denied

Either windows or linux, as root or user, I get a permission error.

here is my smb.conf:

# Global Preferences

[global]
workgroup = workgroup
netbios name = file-server
server string = Linux Samba Server
encrypt passwords = yes
security = user
local master = no

[homes]
read only = no
browseable = yes
writable = yes

[master]
comment = All data storage
path = /home/west/every
public = no
read only = no
browseble = yes
guest ok = yes
writable = yes
valid users = west
force group = users
valid group = users
write list = west
create mask = 0777

------------------------
fstab file on server:
(The share partition is /dev/hda2)

Code:

/dev/hda3        swap              swap        defaults                  0   0
/dev/hda1        /                 reiserfs    defaults                  1   1
/dev/hda2        /home/west/every  ext3        defaults,rw               1   0
/dev/cdrom       /mnt/cdrom        auto        noauto,owner,ro           0   0
/dev/fd0         /mnt/floppy       auto        noauto,owner              0   0
devpts           /dev/pts          devpts      gid=5,mode=620            0   0
proc             /proc             proc        defaults                  0   0

----------------------
Here is the mount command:
sudo mount -t smbfs //file-server/master ~/smb/every -o rw,umask=000,username=west

Thank you all for your time.

-West

**************
UPDATE 2/4/07

The set permissions on on file-server were:

Code:

drwxr-xr-x  2 root root  16384 2007-02-01 19:50 every/

I changed the partition ID of hda2 with fdisk to:
FAT32 (LBA) - and reformated with: mkdosfs -v -F 32 /dev/hda2

Changed hda2 file system on fstab to vfat and added umask=000 option as well.

Now permissions look like this:

Code:

drwxrwxrwx  2 root root  16384 2007-02-01 19:50 every/

and fstab entry look linke this:

Code:

/dev/hda2        /home/west/every  vfat        defaults,udev=000,rw      1   0

Now I can write from windows to samba server without permissions
errors. I can write from linux to samba server only on root.

---
*****************
UPDATE 2/21/07

New fstab:
(shared partitions are /dev/hda2 and /dev/hdb1)

Code:

/dev/hda3        swap                swap        defaults                0   0
/dev/hda1        /                   reiserfs    defaults                1   1
/dev/hda2        /home/west/lin      reiserfs    defaults                1   2
/dev/hdb1        /home/west/win      vfat        rw,umask=002,gid=users  1   0
/dev/cdrom       /mnt/cdrom          auto        noauto,owner,ro         0   0
/dev/fd0         /mnt/floppy         auto        noauto,owner            0   0
devpts           /dev/pts            devpts      gid=5,mode=620          0   0
proc             /proc               proc        defaults                0   0

New file server smb.conf:

# Global Preferences

[global]
workgroup = workgroup
netbios name = file-server
server string = Linux Samba Server
encrypt passwords = yes
security = user
local master = no
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

[homes]
read only = yes
browseable = no
writable = no

[win]
comment = All windows data sotrage
path = /home/west/win
public = yes
read only = no
browseble = yes
writable = yes
write list = west
create mask = 755

[lin]
commend = All Linux data storage
path = /home/west/lin
public = yes
read only = no
browseable = yes
writable = yes
write list = west
create mask = 755

New command for mounting smbfs:

sudo mount -t smbfs //file-server/lin /home/west/lin-stored -o rw,uid=west,username=west

I added another 40GB HDD as VFAT. See fstab with the new configurations.
I found the umask option for VFAT partition very important. Se man page
for umask, you'll understand why.

But those usefull options are just for VFAT as long as I understood from
the options list for the reiserfs file system.

What was needed in order to have write permissions was the `uid' option on
the `mount' command for `smbfs'

As an extra step I added a few lines to rc.M and created a little new rc.d
script to auto mount

Added after rc.scanluns snippet in rc.M

Code:

# Mounts smb shares on startup:
if [ -x /etc/rc.d/rc.smbmounts ]; then
  echo "Mounting smb shares:  /etc/rc.d/rc.smbmounts"
  . /etc/rc.d/rc.smbmounts
fi

And created the new script called /etc/rc.d/rc.smbmounts:

Code:

#!/bin/sh
#
# This script is to automount smb shares at startup

mount -t smbfs //file-server/lin /home/west/lin-stored -o rw,uid=west,username=west,password=xxx

mount -t smbfs //file-server/win /home/west/win-stored -o rw,uid=west,username=west,password=xxx

Now I have my smb shared mounted at start up with read and write
permissions.

----

archtoad6 · 02-05-2007, 12:48 PM

Thank you for putting the fstab in a CODE block -- much easier to read that way.

I think that changing the shared partition to vfat was overkill & only masked the problem.

I think your real problem lies in the permissions & ownership. How/whence did you run the ls that showed:

Code:

drwxrwxrwx  2 root root  16384 2007-02-01 19:50 every/

I think the umask is masking the problem & the true permissions are still:

Code:

drwxr-xr-x  2 root root  16384 2007-02-01 19:50 every/

What distro are you running on the Samba server? and particularly, what is its default group for a new user?

mokele · 02-05-2007, 04:43 PM

-Quote-archtoad6:
I think that changing the shared partition to vfat was overkill /Quote

You are right. It wasn't necessary. In fact, in my reading and searching
I have found out that FAT partitions (if its true), can't handle files
bigger than 4GB, and I'm not going to risk a limitation like that on a
storage server. So I'm changing back to ext3... I mean, I have to read
and search a little bit more for wich file system is best for this server.

-Quote-archtoad6
I think your real problem lies in the permissions & ownership. How/whence
did you run the ls that showed: /Quote

Code:

drwxrwxrwx  2 root root  16384 2007-02-01 19:50 every/

Right again, I too think permissions are the problem.

I ran `ls' command form: /home/west on the server; where /home/west/every
is the mount point for /dev/hda2

-Quote-archtoad6
I think the umask is masking the problem & the true permissions are still: /Quote

Code:

drwxr-xr-x  2 root root  16384 2007-02-01 19:50 every/

It might be. But the only way I can copy form a linux box to that server is
by umasking to 000 and copying as root. If I don't umask, I get the `permission denied'
error even trying to copy as root.

-Quote-archtoad6
What distro are you running on the Samba server? and particularly, what is its
default group for a new user? /Quote

I'm using Slackware 11, no X, only CLI. Default group for a new user would be
`users'

------------
I'd also would like to point out two new options in fstab and the result
after that.

I added `gid', and `uid' to the fstab file and the entry in the fstab now
looks like this:

Code:

/dev/hda2   /home/west/every  vfat   defaults,udev=000,uid=west,gid=users,rw     1   0

After that the `ls' command shows permissions like this:

Code:

drwxrwxrwx  2 west users  16384 2007-02-01 19:50 every/

To no avail. I still need to copy to server from linux box as root.

I'll keep searching. But I think NFS is best suited for transmission between
linux systems as I have learned so far. I might be wrong on this one thou.
I read somewhere that Samba is the best way to handle file sharing when used as
a DC. Now, thats overkill for what I'm trying to do here.

regards.

-West.

wildar · 02-05-2007, 05:25 PM

For troubleshooting purposes set "security = user" to "security = share" and restart smb. If it works, did you remember to run "smbpasswd"? If you did, then you'll need to insert "smb passwd file = <path to smbpasswd>".

mokele · 02-05-2007, 06:32 PM

wildar

security was set to `share', added line `smb passwd file = /etc/samba/smbpasswd',
re-entered user `west' with `smbpasswd' command, Still get the `Permission denied'
as regular user, but can write as root.

I think that was enough sparring. I'm moving to NFS for linux transfers. Thats
about another guide to start reading.

If anyone figure this one out please post.

Thanks to archtoad6 and wildar for your replys

archtoad6 · 02-07-2007, 04:37 PM

I think it's really basic -- you need to change the permissions on the server. 1st, you need to decide Who needs Which kind of access to What.

It sounds like this drive, i.e. filesystem, is a common area, open to all; so, there are 2 ways you can do this: quickly or cleanly.

Quick
The quick way is to just add "write" to all permissions:

Code:

chmod -R a=rwX /home/west/every

Of course this is done as root on the server. I will leave it to others or another post to discuss why this is not very clean.

Clean
The clean way is only a little more complicated:

Change the group ownership of the entire filesystem, files & directories alike, to "users". Or you could make new special group, like "west", that will consist of all users allowed access.
Use chmod to grant conservative access rights -- no world write, no execute at all.
"Fix" the execute bit on dirs., & set them to assign all new files to their group, not that of the file's creator. This keeps things clean, uniform, & communal.

Code:

cd /home/west/every
chgrp -R users .
chmod -R ug=rw o=r .
find . -type d exec chmod g+s,a+X {} +

If there are any truly executable files, you will have to fix their permissions. If there is a significant number,
file might help identify the ones which need to be made executable again.

RT

M's
I re-read these in formulating my answer:

chmod
chgrp
find
file

I also looked at:

ls
test

Warning
While I re-read the above man pages & my code carefully, I did NOT have a handy test target, so I did NOT run the above code on a live filesystem. Make the appropriate test before you risk anything important. This code may not be destructive of file contents, but unscrambling a mistake could be time consuming.
You have been warned!