Mount a windows share in FreeBSD/Unix permanently?

[wesleyw]

Using mount_smbfs how would i go about permanently mounting a windows share abcd for instance onto the unix box?

 

 

Wes

[webman]

Using /etc/fstab. Something like this.

[wesleyw]

I've manage to get it all working with the mounted share to a windows box however when I try and run moodle it brings up time after time a session has timed out message which happens when the permissions on the directory are incorrect I have however made sure that this is not the case with the moodle user having full access to the shared area but it still brings this up do you have any ideas why this may be the case?

 

Wes

[tom_newton]

Wes - directory mask errors?

 

FWIW, my (linux) fstab contains lines such as:

//sotonfs/world /mnt/shares/soton smbfs credentials=/root/smb.soton,dmask=777,fmask=666 0 0

 

where /root/smb.soton is (passwords blanked out!)

username = tom

password = #######

[webman]

Don't know to be exact... are you sure that the user that apache runs under can access the mountpoint? IIRC, the mount point will need the permissions applied to it before mounting anything.

[wesleyw]

webman yep you're right the www user can't write to the share how would I add the unix user to the file permissions of the windows share say the unix box name is unix and the user is www?

 

 

Wes

[webman]

To be honest I don't know what the best practice is for this with regards to system permissions and apache needing write access. I'd imagine a chown /mnt/moodledata www would do the trick (while unmounted).

 

*Gets binoculars out to look for Geoff*

[CyberNerd]

you shouldnt need to change perms after, they can be set during the mount

 

http://samba.org/samba/docs/man/manpages-3/smbmount.8.html

 

see toms post.

 

fmask=

 

sets the file mask. This determines the permissions that remote files have in the local filesystem. This is not a umask, but the actual permissions for the files. The default is based on the current umask.

dmask=

 

Sets the directory mask. This determines the permissions that remote directories have in the local filesystem. This is not a umask, but the actual permissions for the directories. The default is based on the current umask.

[CyberNerd]

uid=

 

sets the uid that will own all files on the mounted filesystem. It may be specified as either a username or a numeric uid.

 

uid=www

[webman]

Thanks CyberNerd, learn something new every day

[Geoff]

*Gets binoculars out to look for Geoff*

 

No, you need to give effective uid and guid permissions as an option to the mount command.

 

Thus if I had Apache running as uid 'www-data' and guid 'nobody' and wanted it to be able to access '/var/moodledata' which was actually a mounted smbfs share sitting on '\\fserver01\moodledata' accessable with the login name of 'someuser' and a password of 'somepassword',I'd need an fstab line that looked like this:

 

//fserver01/moodledata    /var/moodledata   smbfs    defaults,user=someuser,password=somepassword,uid=www-data,gid=nobody  0       0

 

Care must be taken if the remote share is writeable by anyone else. It may be necessary to set a file mask and/or directory mask (with the fmask= and dmask= options respectively). that enable the 'sticky bit'.

[wesleyw]

Well that is now working thanks to you guys! Phew!

 

 

Wes

[webman]

Thanks Geoff, that's handy for me too...

[wesleyw]

"Care must be taken if the remote share is writeable by anyone else. It may be necessary to set a file mask and/or directory mask (with the fmask= and dmask= options respectively). that enable the 'sticky bit'."

 

What could happen with this then Geoff? Sticky bit?

 

 

Wes

[Geoff]

Sadly the interaction between Samba and a Windows server isn't always entirely predictable. Depending on the NTFS permissions on the server, you could end up with files the web server can't write too or no-one else can read. You can force the issue with the fmask and dmask options.

 

Alternatively, if you have a recent version of Linux, enable POSIX ACL support for your filesystem. That way, the Linux file permissions model is much closer to how Windows works.

[tom_newton]

Sticky bit = these permissions pass down to files created underneath this directory. IIRC. WIPD.