Windows Network Drive Linux монтирования требует sudo после монтирования

340
Legit Stack

Я могу смонтировать диск в Linux с помощью sudo.

sudo mount \ -t cifs \ -o 'vers=3.0,username=myuser,domain=mydomain' \ '//windows-ip/share-folder' ~/testmount/

Это прекрасно работает, проблема в том, что когда я захожу в ~ / testmount и делаю что-то вроде mkdirэтого:

mkdir: cannot create directory ‘bkup’: Permission denied

Это будет работать, если я использую. sudoУ нас будет автоматический скрипт в cronjob для записи файлов на эти монтирования, поэтому нам нужно иметь возможность писать на монтирование без него sudo.

Так что после того, как он смонтирован, я не могу добавлять файлы в эту папку, если не использую, sudoи в этом проблема.

Кажется, моя проблема очень похожа на эту, но решения для нее не сработали:

https://unix.stackexchange.com/questions/231230/mount-successful-directory-accessible-but-cannot-do-operations-cp-mkdir-etc

Кто-то предположил, что проблема заключалась в том, что я использовал sudo для его монтирования, и поэтому мне пришлось использовать sudo, чтобы что-то изменить в нем (даже если мне не нужно использовать sudo для чтения содержимого в нем).

Итак, я нашел ответы, подобные этим:

https://unix.stackexchange.com/questions/365308/use-mount-o-with-a-non-root-user https://wiki.ubuntu.com/MountWindowsSharesPermanently

Я даже пытался реализовать предложенные решения, но так и не смог заставить их работать.

В моем файле etc / fstab есть такая строка:

//windows-ip/share-folder \ /home/mysuer/testmount \ cifs \  uid=myuser,credentials=/home/myuser/.smbcredentials,iocharset=utf8,domain=my-domain 0 0

При вышеописанной настройке, когда я пытаюсь запустить mount без sudo, я получаю сообщение об ошибке:

$ mount ~/testmount mount: only root can mount //10.1..../shared on /home/.../testmount

Причина, по которой мне нужно иметь возможность писать в эти подключенные папки без sudo, потому что у нас будет автоматическая система сохранения файлов, и я не думаю, что она должна использовать sudo, и я даже не знаю, может ли она, если бы мы этого хотели ,

Я нахожусь на centos 7. Возможно, вы не можете поместить опцию 'domain' в fstab, я не знаю. Кто-нибудь может мне с этим помочь?

1

1 ответ на вопрос

1
Kamil Maciorowski

Монтирование и последующий доступ - это две разные вещи.

Чтобы пользователи могли монтировать, четвертое поле fstabдолжно содержать user, например user,uid=myuser,…. См man 5 fstab. Возможно, вам это не нужно, продолжайте читать.

Вы даете uid=myuserвариант. От man 8 mount.cifs:

uid=arg
устанавливает uid, которому будут принадлежать все файлы или каталоги в смонтированной файловой системе, когда сервер не предоставляет информацию о владельце. Он может быть указан как имя пользователя или числовой идентификатор пользователя. Если не указано, по умолчанию используется uid 0. mount.cifsПомощник должен быть версии 1.10 или выше для поддержки указав идентификатор пользователя в нечисловой форме.

Еще один фрагмент:

mount.cifs -V Команда отображает версию помощника по монтированию cifs.

Если uid=указано правильно, монтаж с помощью sudoне должен отменять его; так что вам может даже не понадобиться userопция в fstab. Может быть, вы были почти там, когда вы использовали, uid=но вы сосредоточены на том, чтобы не использовать sudo. Есть еще одна вещь, хотя. Еще один фрагмент:

Основной протокол CIFS не предоставляет информацию о владельце Unix или режим для файлов и каталогов. Из-за этого файлы и каталоги, как правило, будут принадлежать тем или иным значениям параметров uid=или gid=, и для них будут установлены разрешения по умолчанию file_modeи dir_modeдля монтирования. Попытка изменить эти значения через chmod/ chownвернет успех, но безрезультатно.

Когда клиент и сервер согласовывают расширения Unix, файлам и каталогам будут назначены uid, gid и режим, предоставляемые сервером. Поскольку монтирования CIFS, как правило, являются однопользовательскими, и одни и те же учетные данные используются независимо от того, какой пользователь обращается к монтированию, вновь созданные файлы и каталоги, как правило, получают право собственности в соответствии с теми учетными данными, которые использовались для монтирования общего ресурса.

Если используемые uid и gid не совпадают на клиенте и сервере, могут быть полезны опции forceuidи forcegid.

Если я правильно понял, клиент и сервер (при правильной настройке) могут игнорировать uid=и использовать права собственности, хранящиеся на сервере. В этом случае это актуально:

forceuid
поручает клиенту игнорировать любые uid, предоставленные сервером для файлов и каталогов, и всегда назначать владельца в качестве значения uid=параметра.

Похоже, что эта строка fstabможет работать лучше для вас:

//windows-ip/share-folder \ /home/mysuer/testmount \ cifs \  forceuid,uid=NUMBER,credentials=/home/myuser/.smbcredentials,iocharset=utf8,domain=my-domain 0 0

Затем вы монтируете с помощью sudo(или добавляете userопцию, если она вам действительно нужна). Без noautoопции ОС попытается автоматически смонтировать общий ресурс при загрузке. Сеть может быть еще не доступна в то время, я не знаю, решит ли это ваша ОС. С помощью systemdвы можете использовать x-systemd.automount, четвертое поле будет начинаться с:

x-systemd.automount,x-systemd.idle-timeout=1min,forceuid,uid=NUMBER,…

Альтернатива есть autofs.

Похожие вопросы