Assigning permissions/ownership of a mounted network share?

[rwheelock83]

By Googling around a bit, I was able to learn enough to add this line to my fstab file in my Fedora 13 system:

 

Code:

//192.168.1.101/e /mnt/e cifs auto,username=USER,password=*****,rw,umask=000,gid=500 0 0

 

Once I'm logged in, I notice (every time) that it has logged the following boot message:

 

Code:

Mounting CIFS filesystems:  mount error(101): Network is unreachable
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
[FAILED]

However, the share is mounted and I can access files on it.

 

The error log doesn't bother me as much as the fact that my user account has read-only access to the share. I've tried messing with the umask and/or uid tag, but no luck as of yet. What's the best way to give a specific user (or even all users if that makes it simpler) full access to the share?

 

Thanks!

[Dungeon-Dave]

You have three things to consider:

1. what (server) credentials is the mount using on the remote server (the USERNAME= part)

2. what (local) credentials will new files be written as (uid=,gid=)

3. what permissions are on the directory located on the server.

 

For testing: try writing a file from the local machine to the mount point and look on the remote machine to see what ownership the server believes the file is. Then try writing several files as different local users to see if they all appear to be owned by the same remote user (they should be).

 

For testing of this type, I often find that it's remote server permissions that get in the way. With Windows sharing, I used to leave the share "all users=read/write" then lock it down using NTFS permissions. For testing, I left the dir as "all users: modify" (I'm wary of giving them "full control") then check server-side to see who Windows believes the connecting user to be. Often I've found it to be "guest" because it rejected the username/pass combination yet still allowed guest access - meaning later problems.

 

Also, check the server logfiles for information relating to the CIFS error. It could simply be something minor on the Linux side that can be safely ignored, but still worth checking. A quick Google shows that maybe the _netdev option could help (see this post from Ubuntu forums to give it a slight delay)

 

Hope that helps!

[rwheelock83]

The server credentials are a username that has full access to the share. I can use the same credentials to "Connect to Server" and have full read/write, but not when trying it from the mount point.

 

I haven't yet figured out how to write a file to the mount point... From the GUI, the folder permissions of the mount point indicate that the root is the owner, and my user account is given Access level. Is there a way to elevate to the root from within the GUI (as in Windows) to change those permissions, or does that need to be done from a Terminal (and how would I do that)?

 

Thanks for your help!

[rwheelock83]

Well, I discovered yesterday that if I use "Connect To Server" to access the share, I then have read/write access via the mount point. If I reboot though, it's back to read only until I use the network path again. That suggests to me that it could be an authentication issue as far as the Windows box is concerned.

[Dungeon-Dave]

Examining audit logs on the Windows box should tell you if that is the issue.

 

Note that there should be Linux logfiles talking about remote authentication - check /var/log/secure or /var/log/messages for more info, there should be some report of a successful mount/login, possibly something about the user account also.

[Dungeon-Dave]

Is there a way to elevate to the root from within the GUI (as in Windows) to change those permissions

Some distros - uBuntu, for instance - allow priv escalation via graphical means. However...

or does that need to be done from a Terminal (and how would I do that)?

.. it is better to perform this within a priv'd user session, rather than elevate whole GUI (or application) to perform the same operation.

 

From the terminal window, use "sudo -i" (or "su -") to become root, if necessary.

Then use the "chown" or "chmod" commands to change owner or mode (permissions).

 

Use the "man" command to obtain information about a specific command, eg "man chown".

[rwheelock83]

Well, I feel like an idiot. Apparently, I had given myself (on the server) read only access to the root of the share, but read/write to various folders within the share. I blame my own inconsistency of where I checked for write permissions for most of this one. It does indeed allow me to write to the folders for which I have full access to. (And after installing the latest F13 updates, the CIFS error in the log disappeared too.)

 

One of the issues I had been trying to solve here was using Local Folders in Mozilla Thunderbird to point to a location on the mapped network share (ultimately so I could access the same Local Folders from different computers and/or OS's on my home network). It would read the folders, but somehow corrupted several of the folder names, and wouldn't display emails. I had assumed that this was a read/write permission issue, but apparently that's not the case.

 

Thanks for putting up with my ignorance! lol

[Dungeon-Dave]

Well, I feel like an idiot. Apparently, I had given myself (on the server) read only access to the root of the share, but read/write to various folders within the share. I blame my own inconsistency of where I checked for write permissions for most of this one. It does indeed allow me to write to the folders for which I have full access to. (And after installing the latest F13 updates, the CIFS error in the log disappeared too.)

Good, good. All worky then!

 

One of the issues I had been trying to solve here was using Local Folders in Mozilla Thunderbird to point to a location on the mapped network share (ultimately so I could access the same Local Folders from different computers and/or OS's on my home network). It would read the folders, but somehow corrupted several of the folder names, and wouldn't display emails. I had assumed that this was a read/write permission issue, but apparently that's not the case.

Thunderbird usually stores mailboxes in some format (I don't think it's mbox format) but the actual character encoding may differ between OSes.

 

If you want the possibility of reading mail from anywhere, then the mailboxes need to be stored (and accessed) in a common format between OSes. Rather than use file-sharing, you may be better off using IMAP, in which the mailbox is stored centrally on the Linux box and all clients talk the same protocol to access this mailbox (note that the client may not always need to be Thunderbird - any IMAP-compliant client will do).

 

I've configured my server to keep all mailboxes stored on it, then use courier-imap (did use dovecot but had issues) to access them. However, my server also runs mail services for me, so can send and receive via this mailbox also.

 

Thanks for putting up with my ignorance!

Ah, it's a noob forum - it happens!